MPLS cisco QOS VPN full 139923 presentation

Lucent’s MPLS IP VPN approach - Key Features • Submitted to IETF for RFC approval • Unique VPNID within the Service Provider network • Use of existing routing protocols without modificat

10/23/19 Lucent Technologies – Proprietary

MPLS Virtual Private Networks

Peter Joy

Senior Product Marketing Manager

TM

Shared IP Network

• Layer 3 - Any to Any connectivity

• Security, reliability, performamce,

Maturity Decline

Circuit Switch Voice

Internet Frame Relay

ATM

Private Networks

Networking industry trends

• The industry’s First baseline MPLS implementation

• Uses standard IP protocols - OSPF, BGP-4, RIP-2

• Maps connectionless IP through switched core

• Entire backbone appears as single QoS aware hop

• Uses advanced label switch path aggregation technology (MPT) to minimize the use

of virtual circuit resources

• Provides Absolute QoS in the core-mapping IP to ATM class of service

IP Navigator/MPLS

Lucent’s MPLS IP VPN

approach - Key Features

• Submitted to IETF for RFC approval

• Unique VPNID within the Service Provider network

• Use of existing routing protocols without modification

• Easy configuration/adding of new sites - equivalent to

adding a new logical port

• User Security - uses industry standard router security

• Dynamic of discovery of virtual routers within the VPN

• Highly scalable - no pre-allocation of resources

• Use of private and unregistered address space allows for ease of enterprise adoption

What are Virtual Routers?

• Logically independent routing domain for each VPN

• Each virtual router is NOT a separate operating system“task”

• Resides only at edge of SP network

• Logically equivalent to a physical router (filters, interfaces, access lists, configuration, management, monitoring,)

• Virtual Routers in a VPN represent a virtual routing domain and dynamically discover each other in the service provider network

• Customer view is similar to Ethernet LAN connected routers

• Carrier management similar to layer 2 services

Traditional IP Enterprise Network

Traditional method:

-PVC or leased line connections -Fully meshed cost prohibitive or difficult to manage

CE Router

Customer B Headquarters

Customer B Dallas Branch

CE Router

CE Router

Customer A Boston Branch

B-STDX 9000

B-STDX 9000

B-STDX 9000

CBX 500

CBX 500

HQ

HQ

LA Boston

LA Dallas

Customer A VPN

Customer B VPN

Physical Topology View

Logical VPN View

Multiple MPLS IP VPNs

Accessing the VPN

Customer A Branch (Boston)

Customer C

HQ (NY)

Customer C Branch (Dallas)

• Ingress IP interfaces allow IP VPN traffic

to access the Lucent network.

• For IP logical ports that use frame relay, each IP VPN that uses the lport has one or more DLCIs A DLCI is associated with a particular VPN

• For ATM, each VPI/VCI is associated with each VPN

• For PPP or Ethernet, a single IP VPN owns the port

• When a DCLI or VPI/VCI is assigned to a VPN for the first time in a switch, a VR

is created for the VPN

VR-A

Auto-Discovery/Routing Within a VPN

Switch-C internal H/W address= 150.202.79.12 VR-C

VR-B

Switch-A internal H/W address=

150.202.78.12

Service Provider’s Network

Switch-B internal H/W address =150.202.77.2

Customer A

HQ (Chicago)

Customer A Branch (Boston)

Customer A’s Vendor

• Each VR is automatically assigned a class D multicast address (internally

in SP network only) in the form 239.192.x.x (x.x is the VPN ID, which is

assigned when the VPN is added and uniquely mapped to the specific VPN)

• Allows a VR to discover and be discovered by other VRs

• IGMP allows VRs to join a multicast group(VPN)

EXAMPLE:

• To get VR-Bs address (switch-Bs address) VR-A sends an ARP request

packet with the address of VR B as the logical address This ARP request is

encapsulated in this VPNs multicast address (239.192.0.1) and sent out

Switch B recognizes the VPN address and responds with the switch

“hardware” address

• This response is sent to the VPN multicast address

Extranet connection to the parts database reachable through VR-B advertises a default route to VR-B VR-B exports only 165.1.1.1 to VR-C

to keep the corporate network secure

Parts DB 165.1.1.1

IP Interface (150.1.1.2)

IP Interface (150.1.1.3)

IP Interface (150.1.1.1)

Customer A Branch (Portland)

• Point to Point LSP

– A predefined path between any two switches within a VPN

– Useful for traffic engineering

– UBR, ABR , nrt-VBR, rt-VBR

• Policy Based Forwarding LSP

– Based on filter match

– PVC is switch to switch or switch to lport

– UBR, ABR , nrt-VBR, rt-VBR, CBR

• Best Effort LSP (default)

– UBR/ABR

– As secure as other switched services - Frame/ATM

VPN Management

Fault Security

Performance

Acc’t Accounting Server

Statistics Server & Report Generator Provisioning Server

Fault Server

CNM Gateway SLA Reports

Services Software

Systems

Planning & Consulting

Network Implementation

 Network Planning and Design

 NOC Design Services

Global “Direct Touch”

 Network Planning and Design

 NOC Design Services

NetCare™ Services

Core IP VPN Test Environment

• Network used by software

development

• Comprised of several device types:

– 8-10 GX-550 Nodes– 10-16 CBX-500 Nodes– 18-20 B-STDX 9000 Nodes– Several DS-3-HSSI CSU/DSU Devices– Lucent NavisCore NMS Support

– Assorted tools (Linux, other hardware)

Current “Top Level” Network Map

Lab Performance Snap Shot

•Testing so far has confirmed high scalability

•255 VPNs currently tested in network - more to be added

•500+ IP routes/VPN

•Full convergence time generally is 5-10 minutes

•Memory requirements on the CP/SP are well within limits

•After a switch is removed completely from a fully converged network, the remaining switches all wait for the OSPF dead timer to expire - within 10-20 seconds all of the routes

associated with that neighbor in each VPN it was participating in are removed and the remaining network converges with little

10/23/19 Lucent Technologies – Proprietary

Technical comparison to the BGP overlay approach

Comparison to BGP “overlay” model -

Scalability of configuration

• In the VR approach, each connection to the network

requires one Layer 3 configuration

• In the overlay approach, each connection to the the

network requires Route Distinguisher (RD), Route Target (RT), Site Of Origin (SOI), VPN of Origin (VOI)

• Requires no changes to existing, standardized protocols

• All configuration is standard router configuration

• The overlay approach uses a route distribution

methodology described in RFC 2547, but requires significant changes to BGP, an existing Internet standard

Comparison to BGP “overlay” model

-Additional IETF standards/proposals

required for operation

• The VR approach simply makes use of standards such as routing protocols and ARP which are router requirements set forth in existing RFCs

• The overlay model requires the additional

implementation of the following drafts:

– draft-ietf-idr-bgp4-multiprotocol-v2-02.txt – draft-ietf-mpls-bgp4-mpls-02.txt

– draft-ietf-idr-bgp4-cap-neg-03.txt – draft-ramachandra-bgp-ext-communities-01.txt – draft-chen-bgp-route-refresh-01.txt

– RFC 1997

Comparison to BGP “overlay” model

-Rules for network configuration and

operation- CE peering requirements

• Since the VR approach is based on standard routing

protocols and routing domains, there are no special rules for how to connect customer sites to the core network

• The overlay approach requires network administrator

and CPE administrator implementation of special configuration rules

Comparison to BGP “overlay” model

-Rules for network configuration and

operation (CE peering requirements)

• If RIP is run to the CE, it is required that the PNA configure the multi-homed CE correctly to NOT leak routes distributed from PE to another PE.

• If OSPF is run to the CE, it is required that the site be run as 1 large OSPF area with the CE being the area border router.

• Additionally, it is required that the PE should be in a different area and the PE report no inter-CE links.

• RFC 2547 does not specify if other special rules apply for other protocols, e.g., ISIS.

• A new and special parameter "SOI" has to be configured to ensure routing loops are avoided

Comparison to BGP “overlay” model

-Dynamic discovery of VPN endpoints

• The VR approach specifies a methodology for the

dynamic discovery of other VRs in the network using IP multicast facilities A manual override for completeness

Comparison to BGP “overlay” model

-Routing protocols between VPN

endpoints

• The VR approach does not mandate the use of a specific protocol within the cloud Examples of protocols include RIP, BGP, OSPF, ISIS

• The Service Provider and/or the Private Network

Adminstrator (PNA) may use any combination of protocols

• The overlay model mandates the use of BGP within the network Per VPN customization based on protocol

suitability is unavailable

Comparison to BGP “overlay” model

-Extensibility

• Since the VR approach merely seeks to provide real IP

router facilities to all VPNs, it is automatically extensible

to support other IP applications and technologies such as Multicast

• No new architecture will be required Every new

application is simply an add-on

• The overlay model is specific to BGP and new services

will require new architectures

Comparison to BGP “overlay” model

-VPN endpoint granularity

• The VR approach treats the VRs as independent IP

routers

• VRs can be of any size - one VR could use memory for a

1000 routes while all others use memory for only 2 routes each

• The overlay model requires that all routes in a VPN be

stored in all PEs that participate in that VPN This implies that the size of the routing table in the PE having the

largest number of routes in the VPN determines how much memory is used up in ALL PEs

Comparison to BGP “overlay” model

-Private network autonomy

• The VR approach allows the full range of autonomy from none to full - Private Network Administrator (PNA) may

be allowed to fully manage the Layer 3 resources provisioned for that VPN by the Service Provider Administrator (SPNA)

• The overlay model does not allow the PNA to configure and manage the VPN end-to-end This is not configurable from VPN to VPN Specifically, IP savvy SPs who buy VPN services from a larger SP will be unable to control their destiny - applies to provisioning as well as end to end troubleshooting and monitoring

Comparison to BGP “overlay” model

-Interconnection of VPNs

• Both approaches allow for the interconnection of

different VPNs to be fully configurable

• In the VR approach, the interconnection of VPNs is

simply a matter of provisioning a connection between the VRs

• In the overlay model, all the sites in an extranet have to

be pre-selected and placed in a unique VPN

Comparison to BGP “overlay” model

-Data security

• The VR approach utilizes a separate routing table for

each VPN Packet processing has to utilize Layer 2 markings to select the routing table to be used for further forwarding This implies that for a VPN to accidentally leak a route or data from to another intentional corruption will be necessary

• The overlay model utilizes an integrated per-site

forwarding routing table This has the implication that accidentally leaking a route or data is easy since only specific fields of the routing table entry need to be corrupt

Comparison to BGP “overlay” model

-QoS

• The VR approach specifies that forwarding quality is

configurable for each pair of VRs and on a VR port level This implies that forwarding data could be configured to utilize policy-based forwarding or point to point VPN private LSPs or use the backbone best effort LSP

port-by-• The Overlay approach does not specify any specific QOS methods available for VPN data forwarding and indeed is best efforts only

address space, it is possible to make the aggregate cost be something much less)

• In general, 2 memory accesses for routing table and link state

Comparison to BGP “overlay” model

-Performance

• In the VR approach, standard routing protocols is used end to end Routing performance is fully dependant on standard factors

• For instance, if ISIS is chosen, the Djikstra cost is

dependant on the number of links and the number of nodes This cost is simply additive across all VPNs

• The overlay model utilizes non-standard BGP routing and routing performance is partially unknown

Comparison to BGP “overlay” model

-Performance

• The overlay model utilizes inbound route filtering which

is very inefficient on router receive memory, router transmit memory, network bandwidth and with respect

to memory used for routing information bases

• Since the overlay model does not utilize a dynamic

neighbor discovery mechanism, when an existing VPN is added to a PE, it has to use the route refresh mechanism

to seek routes from other PEs that have routes in this VPN

• This is a non- scalable utilization of network bandwidth

Comparison to BGP “overlay” model

-Control bandwidth usage

• The VR approach uses approximately 50 bytes per VPN per SPED per hour This is the only overhead Since

standard routing protocols are used and since neighbor discovery is dynamic, outbound route filtering is

employed to minimize usage of core bandwidth

• The overlay approach uses only inbound route filters

This means that much network bandwidth is wasted on sending routes to routers that don’t need them

Comparison to BGP “overlay” model

-Upgrade to network based VPN

service

• The VR approach treats the new VR as simply an

additional VR in an existing IP domain This means that tunnels (IPSEC etc) are not disrupted

• The overlay model hides CE addresses from other CEs, breaking the operation of tunnels