1. High Capacity Service Provider
Design using GPMLS for IP Next
Generation Networks
Tauqir Azam, Rishika Mehta, Ashish Tanwer
Aricent Group, Gurgaon

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

3. Abstract
 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

4. Introduction
 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).

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

6. IGP 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.

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

8. Virtual Routers: VPN Routing
and Forwarding (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.

9. Identifying VPN routes: The Route
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.

10. Controlling Route Distribution: The
Route Target 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

11. How 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.

12. How 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

13. Peer 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.

14. Segmented-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.

15. Overlay 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.

16. MP-BGP/GMPLS VPN Configuration

17. Hardware Design

18. Hardware Design Using CISCO Products
 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

19. Hardware Design Using JUNIPER Products
 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.

20. Hardware Design Using Ciena Products
 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.

21. Conclusion
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

22. [1]
References
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

23. QUESTIONS