High Capacity Service High Capacity Service Provider Design using Provider Design using GPMLS for IP Next GPMLS for IP Next Generation NetworksGeneration Networks

Tauqir Azam, Rishika Mehta, Ashish Tanwer

Aricent Group, Gurgaon

ContentsContents Abstract Introduction Service Provider internal architecture BGP Confederation Virtual Routers: VPN Routing and Forwarding (VRF) Identifying VPN routes: The Route Discriminator

Attribute Controlling Route Distribution: The Route Target

Attribute GMPLS Configuration GMPLS Topology SP Hardware design For Cisco Products For Juniper Products For Ciena Products Conclusion References

AbstractAbstract Our paper outlines the details of internal architecture

of backbone network of Service Provider. The Service Provider provides high performance

using latest extensions on BGP and MPLS & is scalable enough to handle large number of VPN customer sites.

BGP Confederations, Route Targets (RTs) and Route Discriminators (RDs) approaches have been used to optimize the design.

A sample CISCO and Juniper based deployment of the SP (both routing and switching) considering the support of latest protocols, security, power optimization and future extensibility.

Next-generation network implementation is based on Internet technologies including Internet Protocol (IP) and multiprotocol label switching (MPLS). --Wikipedia

IntroductionIntroduction Service Provider is an entity that provides a specific

type of service to its customers like Internet, Application services (like Cloud), Network or backbone services (basically data services) and Telecommunication services (different communication services).

Today, SP of every size and composition are active in the market. Every service provider wants to increase subscribers, services and ultimately, revenues.

As a result, designing better service provider architecture and optimization of service provider architecture is highly demanding task.

Service Provider architecture should be scalable to support future subscribers and future technologies (Next Generation protocols and services).

Service Provider Internal Network Architecture

In our framework, exterior BGP (EBGP) is used to make connection between customer edge (CE) and provider edge (PE).

The routers inside the service provider use interior BGP (IBGP) to connect each other. Interior Gateway Protocol (IGP) is used for internal route propagation.

The configuration does not redistribute BGP into IGP because IGP performance and convergence time suffers if large number of routes are carried and no IGP is capable of carrying full Internet routing table (exceeds 110,000 routes).

To control the route distribution, Route Target (RT) attribute has been used.

The proposed service provider will provide different MPLS based virtual private network (VPNs) to customer sites.

Our service provider emulates virtual routers (VR) on physical router at the software and hardware levels. These VRs have independent IP routing and forwarding tables and they are isolated from each other.

BGP confederation enables to define private autonomous systems with in the public autonomous system

IGP Route PropagationIGP Route Propagation OSPF protocol is responsible to carry route to only for

BGP next hop. It provides optimal path to the next hop and converges

to alternate path so that the BGP peering is maintained. the framework take cares that the internet routes and

not mixed by the service provider internal routes carried by the OSPF.

OSPF take use of its latest Traffic Engineering (TE) Extensions to OSPF, to manage bandwidth of different types of traffic.

BGP ConfederationBGP Confederation The routing protocol IBGP requires full mesh between

all BGP-speaking routers. So a large number of connections and hence a large number of TCP sessions are needed to establish IBGP connectivity.

The traditional service provider design may suffer from unnecessarily duplicated routing traffic. This problem is solved by using latest extension of BGP, BGP confederations.

BGP confederation enables to define private autonomous systems with in the public autonomous system.

Virtual Routers: VPN Virtual Routers: VPN Routing and Forwarding Routing and Forwarding (VRF)(VRF) To maintain security, it is necessary to constrain distribution of routing information at PE that has sites from multiple (disjoint) VPNs attached to it.

The solution of problem is that PE must maintain multiple Forwarding Tables, one table per set of directly attached sites with common VPN membership e.g., one for all the directly attached sites that are in just one particular VPN.

Routes receives from other PEs (via BGP) restricted to only the routes of the VPN(s) the site(s) is in via route filtering based on BGP Route Target (RT) Attribute.

Identifying VPN routes: The Identifying VPN routes: The Route Discriminator AttributeRoute Discriminator Attribute To maintain security, it is necessary to constrain distribution of routing information

at PE that has sites from multiple (disjoint) VPNs attached to it. Route distinguisher is used to uniquely identify VPN routes in the SP core. Route distinguisher, is a 64-bit value defined uniquely for each user group. To ensure VPNv4 route uniqueness, the customer IPv4 routes are prepended with a

uniquely defined RD to create a distinct VPNv4 prefix. Every VRF configuration requires an RD to be defined. Its uniqueness guarantees

customer VPNv4 uniqueness.

Controlling Route Controlling Route Distribution: The Route Distribution: The Route Target AttributeTarget Attribute In order to maintain security it is necessary to constrain distribution of

routing information at PE that has sites from multiple disjoint VPNs attached to it. To constrain the distribution of routing information, the sites connectivity is controlled by BGP policies.

One of these attributes is the route target (RT), which is an extended community BGP attribute.

In MP-BGP, when a VPN route learned from a CE router is injected into VPNv4 BGP, a list of VPN route target extended community attributes is associated with it.

The export route target is used in identification of VPN membership and is associated to each VRF. Each VRF ‘imports’ and ‘exports’ one or more RTs.

During export route target is appended to a customer prefix when it is converted to a VPNv4 prefix by the PE router and propagated in MP-BGP updates.

A PE that imports an RT installs that route in its routing table. The import route target is associated with each VRF and identifies the VPNv4 routes to be imported into the VRF for the specific customer.

The format of a RT is the same as an RD value. The interaction of RT and RD values in the GMPLS VPN domain as the update is converted to an MP-BGP update

How GMPLS WorksHow GMPLS Works GMPLS extends MPLS to manage time-division (e.g., SONET/SDH,

PDH, and G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber).

Labels for TDM, LSC and FSC interfaces, generically known as Generalized Label.

The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes.

The intention is to cover both the signaling and the routing part of that control plane.

GMPLS includes LSRs devices where switching decision is based on time slots, wavelengths, or physical ports.

The forwarding plane of the devices recognize neither packet, nor cell boundaries and therefore cannot forward data based on the information carried in either packet or cell headers.

Generalized Label extends the traditional MPLS label by allowing the representation of not only labels that travel in-band with associated data packets, but also (virtual) labels that identify time-slots, wavelengths, or space division multiplexed positions.

How GMPLS Works -2How GMPLS Works -2 In GMPLS, a control channel is separated from the data

channel. The control channel is implemented completely out-of-band

because the data channel cannot carry in-band control information.

These devices have either of 5 interface classes, Packet Switch Capable (PSC) interfaces, Layer-2 Switch Capable (L2SC) interfaces, Time-Division Multiplex Capable (TDM) interfaces, Lambda Switch Capable (LSC) interfaces, or Fiber-Switch Capable (FSC) interfaces. –RFC 3945

Peer GPMLS TopologyPeer GPMLS Topology The GMPLS control plane supports an overlay model, an augmented

model, and a peer (integrated) model. In the peer (integrated) model deployment of GMPLS, an NNI allows

the IP/MPLS layer to operate as a full peer of the optical transmission layer.

Specifically, the IP routers are able to determine the entire path of the connection, including passing through the optical cross connects and SONET/SDH optical devices.

Segmented-GMPLS TopologySegmented-GMPLS Topology In the augmented (segmented) GMPLS model, only border routers

receive information from the optical devices and from other routers . The border routers in the four corners between the optical network

and the IP network maintain both routing and optical topology information.

Routers in the IP cloud only maintain topology information for their region, and optical devices only maintain optical topologies within the optical network segment.

Overlay GMPLS TopologyOverlay GMPLS Topology In the overlay model of GMPLS, also called a user-to-network interface

(UNI), the router is a client to the optical domain and interacts only with the optical node that is directly adjacent to it .

The physical light path is decided by the optical network and not by the router.

The goal for the overlay model is to define a signaling message to provision a circuit from a point of presence (POP) in one IP network to an optical network endpoint or through an optical network to another POP in an IP network.

On the UNI no routing protocol is running; it is just a signaling interface.

MP-BGP/GMPLS VPN MP-BGP/GMPLS VPN ConfigurationConfiguration

Hardware DesignHardware Design

Hardware Design Using CISCO Hardware Design Using CISCO ProductsProducts PE routers requires high-performance IP/MPLS features as well

as scalable personalized IP services at the network edge, improve operational efficiency, and maximize return on network investments. Cisco 7600 series routers are ideal for the purpose.

The Cisco 7600 Series is the carrier-class edge router to offer integrated, high-density Ethernet switching, carrier-class IP/MPLS routing, and 10-Gbps interfaces that enables service providers to deliver both consumer and business services over a single converged Carrier Ethernet network.

The processing load on CE routers is much less than that on PE routers and our service provider uses economical Cisco 7200 series Router for the purpose.

For Layer 2 switching, the switch selected must provide the planned network backbone capacity. Since the capacity of service provider depends on the capacity of core switches. Cisco Catalyst 6500 Series Switches are ideal for the purpose.

Catalyst 6500 Series Switches deliver performance of 2 terabits per second (Tbps). The switch fabric delivers 80 Gbps switching capacity per slot and scales to 4 Tbps system capacity

Hardware Design Using JUNIPER Hardware Design Using JUNIPER ProductsProducts PE routers requires high-performance IP/MPLS features as well as

scalable personalized IP services at the network edge, improve operational efficiency, and maximize return on network investments. Juniper MX960 3D Universal Edge Router is ideal for the purpose.

The MX900 3D Universal Edge Router is a high-density Layer 2 and Layer 3 Ethernet platform for service provider Ethernet edge scenarios. The MX960 provides a range of Ethernet services, Including VPLS services for multi-point connectivity.

The processing load on CE routers is much less than that on PE routers and our service provider uses MX480 3D Universal Edge Router for the purpose. Juniper MX960 3D Universal Edge Router is ideal for the purpose.

The MX900 3D Universal Edge Router is a high-density Layer 2 and Layer 3 Ethernet platform for service provider Ethernet edge scenarios.

Switch that can efficiently scale performance and network services, virtualize, secure, and manage network remotely. Juniper EX 8200 Series Switches are ideal for the purpose.

The EX82xx line of modular Ethernet switches is a family of high-performance, highly available platforms for use in high-density 10GbE (10-Gbps) data centers, campus aggregations and core networks.

Hardware Design Using Ciena Hardware Design Using Ciena ProductsProducts For Layer 2 switching, ciena’s 5430 platform is ideal choice. Ciena’s 5430

Reconfigurable Switching System (RSS) is packet-optical switching platform that provides switch fabric capable of switching SONET/SDH/OTN/packet, intelligent multi-layer optical control plane, and compact design, with 3.6 Tb/s switch capacity in a single bay, scalable to 15 Tb/s.

It supports both G.ASON/GMPLS SONET/SDH Control Plane and G.ASON/GMPLS OTN Control Plane.

The architect supports speeds ranging from 155M to 100G in a high-density, energy-efficient platform, the 5430 RSS is a compelling solution for network operators’ metro and core networks.

We can use Ciena’s 6500 transport system in the metro layer of service provider.

Ciena’s 6500 Family Packet-Optical Transport Platform combines Ethernet, TDM, and WDM capabilities for cost-effective delivery of emerging and existing services, from the access edge to the backbone core.

6500 Family Packet-Optical Platform provide chassis capacity of 640 Gb/s giving system capacity of 8.8 Tb/s, supporting 2.5G/10G/40G/100G DWDM, and 2.5G CWDM.

ConclusionConclusion Our paper outlines the internal architecture, network configuration

and hardware design of backbone network of high capacity SP. The service provider design configuration implements the latest

extensions on BGP and MPLS and is scalable enough to handle large number of VPN customer

The service provider design configuration implements GMPLS as replacement of MPLS and the latest extensions on BGP.

The proposed architecture is capable to handle time-division, wavelength (lambdas), and spatial switching. The paper discusses the details of overlay, peer and segmented GMPLS deployment models.

The implementation of GMPLS allows the use of high capacity Dense Wavelength-division multiplexing (DWDM) and ultra-dense WDM (UDWDM) based devices and thus multi folding the capacity of Service Provider’s Backbone Network.

Route Reflectors (RRs) have been replaced by BGP Confederations. Route Targets (RTs) and Route Discriminators (RDs) approaches have

been used to Control Route Distribution and to Identify VPN routes. Service provider hardware requirements and corresponding design

had been discussed. Sample CISCO, Juniper, Ciena based deployment of the service provider (both routing, switching and transport) has been proposed considering the support of latest protocols, security, power optimization and future extensibility.

The presented generic service provider design can be easily modified to provide typically any services that need high capacity Next Generation backbone network

ReferencesReferences[1] Susan Hares et al., “A Border Gateway Protocol 4 (BGP-4)”, n.d., http://tools.ietf.org/html/rfc4271

[2] Y. Rekhter and P. Gross, “Application of the Border Gateway Protocol in the Internet”, n.d., http://tools.ietf.org/html/rfc1772

[3] Curtis Villamizar, Ramesh Govindan, and Ravi Chandra, “BGP Route Flap Damping”, n.d., http://tools.ietf.org/html/rfc2439

[4] Tony Bates, Enke Chen, and Ravi Chandra, “BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)”, n.d., http://tools.ietf.org/html/rfc4456

[5] Enke Chen and Quaizar Vohra, “BGP Support for Four-octet AS Number Space”, n.d., http://tools.ietf.org/html/rfc4893

[6] Yakov Rekhter and Eric C Rosen, “BGP/MPLS VPNs”, n.d., http://tools.ietf.org/html/rfc2547

[7] Dave Katz et al., “Multiprotocol Extensions for BGP-4”, n.d., http://tools.ietf.org/html/rfc4760

[8] Enke Chen <enkechen@siara.com>, “Route Refresh Capability for BGP-4”, n.d., http://tools.ietf.org/html/rfc2918

[9] Yakov Rekhter and Eric C Rosen, “BGP/MPLS IP Virtual Private Networks (VPNs)”, n.d., http://tools.ietf.org/html/rfc4364

[10] Yakov Rekhter <yakov@juniper.net>, “Carrying Label Information in BGP-4”, n.d., http://tools.ietf.org/html/rfc3107

[11] Lou Berger et al., “Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)”, n.d., http://tools.ietf.org/html/rfc4875

[12] Yakov Rekhter and Rahul Aggarwal, “Graceful Restart Mechanism for BGP with MPLS”, n.d., http://tools.ietf.org/html/rfc4781

[13] Eric Gray <egray@zaffire.com>, “LDP Applicability”, n.d., http://tools.ietf.org/html/rfc3037

[14] Daniel O Awduche et al., “RSVP-TE: Extensions to RSVP for LSP Tunnels”, n.d., http://tools.ietf.org/html/rfc3209 ; Kireeti Kompella

[15] Dave Katz, and Derek M Yeung, “Traffic Engineering (TE) Extensions to OSPF Version 2”, n.d., http://tools.ietf.org/html/rfc3630

[16] J. Moy, “OSPF Version 2”, n.d., http://tools.ietf.org/html/rfc2328

[17] R. Hinden, Ed., “Virtual Router Redundancy Protocol (VRRP)”, nd, http://tools.ietf.org/rfc/rfc3768

QUESTIONSQUESTIONS