Junos PDF

White Paper
Optimizing Routing Software for Reliable

Internet Growth
Chuck Semeria
John W. Stewart III
Marketing Engineers
Juniper Networks, Inc.

385 Ravendale Drive
Mountain View, CA 94043 USA
650-526-8000
www.juniper.net
Part Number : 200003-002

Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Internet Routing Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Limitations of Legacy Router Software Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
JUNOS Origins in FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Juniper Networks Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Packet Forwarding Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Routing Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Benefits of the JUNOS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Protected Memory Ensures Operational Reliability. . . . . . . . . . . . . . . . . . . . . . . . 9
Designed Specifically for ISP Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Enhanced Network Stability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Industrial-Strength Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Design for Stability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Design for Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
JUNOS Routing Protocol Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Interior Gateway Protocols: IS-IS and OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Exterior Gateway Protocols: BGP-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Multicast Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Juniper Networks Engineering Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Routing Policy Definition Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
JUNOS Policy Definition Language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Optimizing the Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Testing Policy Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Evolution of Internet Backbone Traffic Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
ISPs Decide Between a Routed Core and an ATM Core . . . . . . . . . . . . . . . . . . . . . . . . 15
Metric-Based Traffic Control in a Routed Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Absence of “Traffic Engineering” across a Routed Core . . . . . . . . . . . . . . . . . . . . 16
Advantages and Disadvantages of a Routed Core . . . . . . . . . . . . . . . . . . . . . . . . . 17
PVC-Based Traffic Control in an ATM Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Traffic Engineering across an ATM Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
The “N-Squared” Problem over ATM Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Advantages and Disadvantages of an ATM Core . . . . . . . . . . . . . . . . . . . . . . . . 20
Traffic Statistics Support Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
The Multiprotocol Label Switching (MPLS) Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Multiprotocol Label Switching (MPLS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
MPLS Packet Forwarding Mechanism: Label Swapping . . . . . . . . . . . . . . . . . . . 23
MPLS and Packet-Forwarding Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Traffic Engineering with MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
The Future of MPLS: Constraint-Based Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
MPLS Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Copyright © 2000, Juniper Networks, Inc.

Contents
User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Command-Line Interface (CLI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Group, Commit, and Rollback Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Configuration Change Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Numerous User Access Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Alternate User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Support for ASCII Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
System Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Secure Shell (SSH) Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Denial-of-Service Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
MD5 Protects BGP Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
SNMP Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
JUNOS Software Delivers Internet Control and Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

List of Figures
Figure 1: Typical Legacy Routing Software Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Figure 2: Routing Engine and Packet Forwarding Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figure 3: Conceptual View of JUNOS Software Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 4: Acceptance and Distribution of Routing Information . . . . . . . . . . . . . . . . . . . . . . 13
Figure 5: Policy Filtering Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 6: A Linear Search vs. a Tree Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 7: Metric Based Traffic Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 8: Example ISP Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 9: ATM Physical vs. Logical Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 10: Logical ISP Topology over an ATM Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figure 11: “N-squared” Problem and PVC Growth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 12: Label Switched Path (LSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 13: A Label Switching Router (LSR) Forwards Packets . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 14: LSP Between an Ingress LSR and an Egress LSR . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 15: Accessing the Command-Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 16: Alternate User Interfaces to JUNOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
List of Tables
Table 1: Traditional Router Cores vs. ATM Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Table 2: Label-switching Forwarding Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Introduction
The Internet is rapidly becoming the public data network of choice. This is demonstrated by
the tremendous growth in user demand and new applications, by increasing mainstream
usage, and by the rise in mission-critical traffic. As customers begin to expect service reliability
and availability similar to the Public Switching Telephone Network (PSTN), Internet Service
Providers (ISPs) are struggling to maintain control in the face of accelerated growth and
increasing complexity.
Legacy router vendors as well as start-ups targeting the Internet core seem to be emphasizing
gigabit, terabit, or “whatever-bit” packet-forwarding performance. The numbers are becoming
so enormous that they’re almost impossible to comprehend. Nevertheless, it should come as no
surprise to anyone close to the networking industry that these speeds are inevitable given the
latest developments in Application Specific Integrated Circuits (ASICs) and Dense
Wave-Division Multiplexing (DWDM) technologies. The critical element that seems to be
missing from all these discussions is the fundamental issue of control. Given all the bandwidth
and forwarding capacity, how do ISPs control and manage their networks as they enter the age
of the optical Internet?
Speed can kill! If you’re racing around Disneyland's Autotopia at 15 m.p.h., control is
important but you probably won’t kill yourself. On the other hand, if you find yourself in the
Indianapolis 500, high-performance brakes, tires, and steering are critical to provide the control
that ensures your survival.
This paper presumes that we have entered the age of the optical Internet and that
high-performance forwarding engines are a fact of life. Juniper Networks has developed
JUNOS Internet software specifically for high-performance and high-growth Internet service
providers. This paper discusses the overall design and a number of the features that Juniper
Networks has implemented to make JUNOS Internet-ready today, while laying the foundation
for control to meet future challenges. When evaluating routing software, it is important to
examine the software architecture, routing protocols, policy definition language, traffic
engineering capabilities, user interface, system security, and network management features.
Each of these characteristics determines the ability of the software to provide the control
needed for ISPs to prosper as they enter the next stage of Internet growth.
Internet Routing Software Architecture

A software’s architecture defines how a system is designed and how its various components
are connected to, and operate with, each other. Most network professionals who are concerned
with routing protocols and router configuration do not take the time to analyze the underlying
architecture that provides the foundation for the system’s operation. As we will see, the
software architecture plays a significant role in determining the network control, stability,
performance, maintainability, and scalability of a complex software system.
Copyright © 2000, Juniper Networks, Inc. 5

Optimizing Routing Software for Reliable Internet Growth
Limitations of Legacy Router Software Architectures

To fully understand the challenges facing legacy routing software architectures in today's
service provider networks, it is necessary to examine the origin and evolution of these software
systems. Initially, router software architectures assumed that the underlying hardware had
only a single CPU and that this CPU was responsible not only for performing real-time packet
forwarding, but also for performing the routing calculations, building routing updates,
managing the user interface, and supporting network management (Figure 1). This
dependence on a single CPU shaped the framework in which the legacy router operating
systems have developed and matured.
Figure 1: Typical Legacy Routing Software Architecture
Packet
Forwarding
User Routing
Interface Protocols
CPU Route
Calculation
Policy Interface
Enforcement Management
Memory
Management
Because legacy routing systems were developed with the assumption that they would support
time-critical tasks (that is, packet forwarding), the designers had to develop an operating
environment that had elements of a real-time operating system. Even though they realized that
general-purpose operating systems provided extremely high levels of system reliability and
stability, they understood that there were a number of inerent performance inefficiencies
resulting from the overhead introduced by memory management and the duplication of effort
across multiple processes. The designers of these legacy routing systems decided that they
should enhance overall system performance by consolidating the code and eliminating the
duplication, even if this meant creating a single, monolithic code base.
In a historic perspective, this decision was probably the best compromise given the
technologies of the time. However, to achieve their efficiencies, the legacy routing systems
incur incredible costs, including the following:
Assume that one part of the monolithic program fails. For example, a task has a memory
leak or an error that causes it to write over another task’s code or data structures. These
types of errors can easily force other tasks to fail and eventually crash the entire operating
system. The only way to recover from this type of failure is to reboot the entire system.
The single monolithic program is required to run in a real-time mode to support
packet-forwarding requirements. Initially, these operating systems allowed packet
forwarding to have priority over all other system tasks. This meant that if the router
became extremely busy forwarding traffic, there might not be enough CPU cycles
remaining for it to complete any outstanding peer updates, hello time responses, or routing
6 Copyright © 2000, Juniper Networks, Inc.

table calculations. This introduces instability into the network, because routing and control
tasks are not completed in a timely manner, resulting in the loss of routing adjacencies and
line protocols.
The overall software architecture becomes so enormous that it loses its flexibility,
scalability, and stability. Modifications become extremely difficult to make because the act
of adding a single new feature can impact the entire code base. For example, has everything
been included that is required to provide a stable implementation? Does the build contain
code that is unnecessary for the application but has bugs that eventually cause the system
to crash? In addition, the size and complexity of the code determine how rapidly a vendor
can issue new software releases to correct acute internetworking problems or add
important new features. Finally, testing a monolithic code base is extremely difficult. No
laboratory can accurately reproduce the conditions found on the global Internet, but testing
issues are further complicated by the need to take the gigantic code base and then test
subsets of it in isolation. This challenge can easily overwhelm any well-designed testing
process.
As we approach the millennium, legacy routing software architectures based on real-time,
monolithic code bases are ill-equipped to support rapid development of features and stable
operation that are required in the Internet core. Today, forwarding traffic in real time over
high-performance optical interfaces mandates the deployment of hardware-based forwarding
engines. As a result, the next generation of routing software does not need to deal with the
competition of resources between packet forwarding and high-level system functions. The
effectiveness of hardware-based forwarding engines permits the routing software to execute in
a general-purpose operating system environment that provides greater reliability, scalability,
availability, and performance for mission-critical applications.
JUNOS Origins in FreeBSD

FreeBSD provides the foundation for the development of a next-generation routing
architecture that has the ability to scale and support the tremendous growth projections for the
Internet. FreeBSD is specifically designed to run on ubiquitous Intel processors. It is very
stable, has a mature networking heritage by virtue of its ancestor running on the Internet since
the early 1970s, and contains a significant code base that can be leveraged in terms of a kernel,
file systems, user accounts, and security.
However, Juniper Networks enhanced and rewrote significant portions of FreeBSD because it
was initially designed to run on host systems supporting a very limited number of network
interfaces. Routers, on the other hand, have significantly more physical interfaces as well as
numerous subinterfaces and a much larger routing table. In addition, the majority of the
networking code was discarded and replaced with industrial-strength implementations that
were capable of withstanding the tremendous stresses imposed by the operational Internet.
The Juniper Networks engineering staff was given the rare opportunity to take their years of
practical Internet routing experience and design a routing architecture from the ground up
without being constrained by the conditions imposed by a legacy routing architecture. This
meant that they could optimize their data structures, plan for a large number of virtual circuits,
and design for efficient storage and searching of huge routing tables. They were free to
implement the latest technology developments supporting traffic engineering and
differentiated service levels and were allowed to place particular emphasis on the design of a
serviceable user interface and a powerful policy definition language.

Juniper Networks Software Architecture

The fundamental design of the Juniper Networks software architecture is to separate control
functions from packet forwarding functions. The Routing Engine manages the routing and
control functions of the system and runs a FreeBSD-derived kernel. The Packet Forwarding
Engine executes in hardware and is dedicated solely to packet forwarding. The clean
separation of these two functions, which permits the delivery of superior performance and a
highly reliable operating system, is illustrated in Figure 2.
Figure 2: Routing Engine and Packet Forwarding Engine
Routing Engine
JUNOS
(CPU-based)
Software
Packet Forwarding Engine

(ASIC-based)
Packet Forwarding Engine

The Packet Forwarding Engine is responsible for performing all packet-forwarding functions.
This represents over 99% of the traffic entering the system. The Packet Forwarding Engine is
composed of several customized ASICs that handle all types of packets and is targeted at the
Internet core. The design and function of the Packet Forwarding Engine will be the subject of
future papers.
Routing Engine
The Routing Engine is responsible for executing the routing processes for the entire system. It
is powered by a processor that provides sufficient compute cycles to support the required
functionality and operate in any networking environment. The Routing Engine runs a version
of FreeBSD that has been customized by the Juniper Networks engineering team for robust
operation under heavily loaded conditions.
Routing protocols, interface management, chassis management, SNMP management, system
security, and the user interface all interact with the operating system as subsystems. Each
program executes as an independent process, complete with its own memory protection. This
removes many opportunities for runaway applications to corrupt each other or the kernel.
Figure 3 provides an overview of the major software design elements of JUNOS.

Figure 3: Conceptual View of JUNOS Software Elements
The JUNOS routing table contains the routes learned from neighbors and through static
configuration. The forwarding table is derived from the routing table and contains an index of
IP prefixes and Multiprotocol Label Switching (MPLS) labels that are actively used to associate
a prefix or label with an outgoing interface. The Packet Forwarding Engine uses the contents of
the forwarding table, not the routing table, to make its ultimate forwarding decision.
Benefits of the JUNOS Architecture

The decision to implement a routing architecture based on separate control and forwarding
planes allows Juniper Networks to deliver a Routing Engine that runs over a general-purpose
operating system. This is a key design feature because it gives JUNOS high reliability,
maintainability, and performance.
Protected Memory Ensures Operational Reliability

Each user process runs in its own protected memory space. This ensures that the failure of one
subsystem will not negatively impact the operation of other subsystems executing over the
operating system. Between these independent spheres of operation, Juniper Networks has
established clean, well-defined interfaces that provide interprocess communication. This
architecture results in a very reliable software system.
Designed Specifically for ISP Networks

Juniper Networks is sharply focused on providing products for high-growth Internet
backbones. This means that Juniper Networks will not have a legacy of operating in enterprise
environments and will not have a monolithic code base that has to be compiled into a number
of different builds to meet the demands of different applications.
Enhanced Network Stability

The Juniper Networks architecture is designed so that transit packets never have to be
processed by the Routing Engine. Of the traffic that is required to go to the Routing Engine,
link-level keepalives and routing protocol updates receive the highest priority to ensure that

adjacencies never go down regardless of the load on the system. This prioritization of control
traffic prevents failures from cascading through the network, because it ensures that links and
routing adjacencies stay up regardless of what else is happening on the system.
Routing Protocols
The soundness of the implementations of the routing protocols is one of the critical factors
governing the successful operation of a service provider’s network. Stability and performance
are essential features for an Interior Gateway Protocol (IGP) to permit the management of
traffic flows within a service provider’s network. The soundness and scalability of the Exterior
Gateway Protocol (EGP) are critical for providing the connectivity and control that is required
between different service provider networks.
Industrial-Strength Routing Protocols

Many network professionals consider interoperability to be the distinguishing factor in
evaluating the soundness of a particular routing protocol implementation. They become
fundamentally concerned with adherence to Internet Engineering Task Force (IETF) standards
and the ability of the software to operate in a multivendor environment. While interoperability
is a critical element that every vendor must meet, it should be viewed as just one of several
components that must be carefully evaluated. There are other strategic elements that hide
“under the hood” of the software and are not immediately visible to the evaluator. It is these
hidden elements that play the most critical role in determining the ability of a routing protocol
implementation to execute in the Internet.
The key elements that distinguish industrial-strength routing protocols from less-capable
implementations are stability and scalability. Stability and scalability don’t occur by accident;
they must be designed into the software architecture from the very beginning of the project. In
a way, the design of routing protocols is comparable to designing an airplane. Some aircraft,
like the Cessna Skylane, are intended to satisfy private aviation requirements. Other aircraft,
like the F-22 Raptor, are hawk-eyed, falcon-fast, and owl-smart. They’re both fixed-wing
aircraft, but they’re intended to function in entirely different operational environments.
Design for Stability

Stability is concerned with the capacity of an implementation to withstand the pressures of
operating in an extremely large network and continue to run for long periods of time without
failure. There are a number of design features that play a critical role in determining the
stability of any routing protocol implementation:
The foresight of the engineer to anticipate and write code that responds to many different
types of failure situations. This includes protocol errors such as malformed packets,
unexpected peer behavior such as the transmission of too many requests/updates, and
simply running out of CPU resources during periods of network stress.
The developer’s skill in providing the right knobs so the router can accommodate a wide
range of different situations.
The willingness of the engineer to write code according to Einstein’s maxim, “Make things
as simple as possible, but no simpler.” This produces an understandable, rapid, and stable
code base.

Design for Scalability

Scalability is concerned with the ability of the implementation to grow with the
ever-expanding network environment. There are a number of factors that play a key role in
determining the scalability of a routing protocol implementation:
Maximum number of interfaces supported
Speed of a routing table search
Maximum number of routes that can be stored in the routing table
Maximum number of OSPF or IS-IS adjacencies or BGP peers that can be supported on each
router
Maximum number of OSPF LSAs or IS-IS LSPs that can be stored in the router’s link-state
database
Ability of the policy control language to permit administrators to easily and efficiently
control the import, export, and modification of an enormous amount of routing
information
JUNOS Routing Protocol Implementations

The Juniper Networks implementations are industrial strength, full featured, and compliant
with all the relevant IETF specifications as well as the deployed base of implementations. Each
ISP’s network design is different and hence stresses routing protocols in different ways. The
Juniper Networks routing protocol implementations have demonstrated their character and
stability by successfully running in several ISP backbones for the past year.
Interior Gateway Protocols: IS-IS and OSPF

The Juniper Networks IS-IS and OSPF implementations are compliant with the IETF’s
specifications. In addition, the Juniper Networks IS-IS and OSPF are complete with respect to
add-on features used by ISPs and have demonstrated interoperability with the deployed base.
Exterior Gateway Protocols: BGP-4

The Juniper Networks BGP-4 implementation is fully compliant with both the IETF’s
specifications and with the deployed base of implementations. Among the full set of features
supported include TCP's MD5 authentication option, communities, route flap dampening,
mesh groups, route reflection, confederations, and peer groups.
Multicast Routing Protocols

JUNOS was designed from the ground up to support IP multicast. Juniper Networks provides
implementations of the Internet Group Management Protocol (IGMP), the Distance Vector
Multicast Routing Protocol (DVMRP), Protocol Independent Multicast, Sparse Mode
(PIM-SM), the Service Announcement Protocol (SAP), and the Service Description Protocol
(SDP). Juniper Networks has and will continue to play an actively role in the design and
development of these standards as well as next-generation proposals.

Juniper Networks Engineering Staff

The Juniper Networks software engineering team is able to deliver best-of-class
implementations of all major Internet routing protocols, including OSPF, IS-IS, and BGP-4. This
expertise extends not only to popular routing protocols, but also to emerging protocols
currently under development in the IETF. The quality of the implementations in JUNOS reflect
the experience and expertise of our staff who have played, and continue to play, active roles in
defining and authoring numerous Internet Drafts and RFCs (Request for Comments).
Juniper Networks has selectively gathered a team of engineers to implement and support
Internet backbone-scale routing protocols for mission-critical environments. Juniper Networks
believes that no other routing vendor, or start-up, can begin to match the quality of this
engineering team. Juniper Networks software experts continue to provide standards
leadership to benefit customers that demand a partner that understands and can design,
deliver, and support protocols that scale with the Internet’s tremendous growth rates.
Routing Policy Definition Language

The routing policy definition language determines what routes are accepted into the routing
table, what routes are advertised to peers, and the specific modifications that are made to
attributes on both import and export. The control provided by the policy definition language is
strategic to backbone networks because it is the fundamental tool that controls how the
networks are used. Policy language determines the paths selected across the Internet and can
play a role in the path selected across the service provider's network.
Figure 4 illustrates how a typical router accepts and distributes routing information. Import
policy is applied as part of the route selection process to manage the acceptance of information
into the local routing table and to manipulate attributes. Information received from peers is
never a candidate for the route selection process unless it passes the import policy filtering
rules. Export policy manages the advertisement of routing information to remote peers. Routes
are never distributed unless they pass the export policy filtering rules.

Figure 4: Acceptance and Distribution of Routing Information
For example, assume that a large ISP provides Internet access to a second-tier ISP that
advertises several hundred routes into the large ISP (Figure 5). The large ISP configures policy
rules so that it accepts only the routes that it expects to receive from the smaller ISP. When the
smaller ISP gets a new customer, it informs the large ISP that it will be forwarding an
additional set of prefixes. The large ISP updates the list of routes that it will accept from the
smaller ISP by modifying its routing policy filtering rules.
Figure 5: Policy Filtering Example
200 Routes
Customers
Small Large
ISP
Internet
ISP
JUNOS Policy Definition Language

A key issue for a routing policy definition language is how easy it is for the network
administrator to manage policy for tens of thousands of routes. The JUNOS policy definition
language is similar to a programming language. It allows policies to be defined that identify
routes based on a number of different attributes (such as IP prefix, AS path, MED, community,
local preference, IS-IS level, and OPSF area) and then take a specific action (such as accept,
reject, and modify) based on those attributes. Because the policy language is like a

programming language, it is very general in nature, permitting it to be extended over time by

simply adding new attributes or new actions. This results in a language that addresses today’s
needs and provides the ability to grow to support future Internet requirements.
Optimizing the Search

It is essential that a policy implementation seek to optimize the performance of the search and
identification process when comparing individual routes against the policy rules. Policy
enforcement requires that each prefix in every routing update be compared to the configured
policy to determine what action should be applied to the particular route. On the Internet,
where exchanges between peers can contain literally thousands of routes, a fast searching
algorithm is required.
Relying on a linear search (O(n)) to identify routes matching a policy takes considerably longer
than performing a tree search (O(log n)) (Figure 6). Legacy routing software typically performs
this search via “access lists” that are linear in nature. Because Juniper Networks had the luxury
of developing its software from the ground up, JUNOS uses a tree search. This is one of the
significant performance enhancements resulting from developing the JUNOS policy definition
language in the late1990s instead of the late 1980s.
Figure 6: A Linear Search vs. a Tree Search
Linear Search (O(n))
Time
Tree Search (0 (Log n))
1 Number of Items
Testing Policy Configurations

An extremely powerful and flexible policy definition language can be a two-edged sword if
there is no way to test the policy before it is placed into a production network. Network
administrators want the ability to pretest their routing policy configurations without affecting
production traffic rather than having customers highlight configuration issues.
In JUNOS, it is possible to define a policy and then test the result of running a prefix with a
given set of attributes through the policy engine. If the policy tests correctly, then the
administrator can reconfigure the system and apply the policy to a production peer.
Traffic Engineering
An ISP must provide a network that is capable of carrying its customers’ traffic. If this standard
is not met, the customers will be unhappy with the service and will find a new provider. At a
very low level, meeting this challenge requires that the ISP provision some number of circuits
of some bandwidth over some geography. In other words, the ISP must deploy a physical
topology that can meet the needs of the customers connected to the network.

Once the physical topology exists, the task of mapping traffic onto that topology must be
tackled. In the past, mapping traffic onto a physical topology was not approached in a
particularly scientific way. Instead, the mapping simply took place as a by-product of routing
configurations. The weaknesses in this haphazard mapping were often resolved by simply
overprovisioning bandwidth. As ISP networks grow larger, as the circuits supporting IP grow
faster, and as the demands of customers become greater, the mapping of traffic onto physical
topologies needs to be approached in a fundamentally different way. The offered load must be
supported in a controlled way and in an efficient manner. This mapping of traffic onto a
physical topology is called “traffic engineering” and is currently a hot topic inside of ISPs and
the IETF.
Evolution of Internet Backbone Traffic Control

In the early 1990s when ISPs networks were constructed over T1 (1.5-Mbps) and T3 (45-Mbps)
links, traffic control was achieved by manipulating routing metrics. Metric-based control was
adequate because Internet backbones were much smaller than today in terms of the number of
routers, the number of links, and the amount of traffic.
Figure 7 illustrates how metric-based traffic control operates. Assume that A sends a large
amount of traffic to C and to D. With the metrics in Figure 7, the A-B and B-C links might get
congested because both the A-to-C and the A-to-D flows go over those links. If the metric on
the C-D link were change to 3, the A-to-D flow would be moved to the A-D link but the A-to-C
flow would stay on the A-B-C links. The result is that the “hot spot” is fixed without breaking
anything else on the network. This is an example of effective traffic control through
manipulating IGP metrics.
Figure 7: Metric Based Traffic Control
ISPs Decide Between a Routed Core and an ATM Core

Around 1994 or 1995, the load on ISP networks was increasing to the point where they simply
had to go faster than T3. At the time, OC-3 interfaces (155 Mbps) were available only on ATM
switches; they were not yet available on router platforms. The ISPs had to make a decision
whether they were going to continue with a routed core or migrate to an ATM core. Each ISP
chartered their future course based on answers to a few questions:
Did the ISP have enough faith in the ability of traditional router vendors to rapidly deliver
OC-3 and OC-12 interfaces for their products?

Did the ISP consider the lack of bandwidth a significant threat to their business that
required immediate resolution, even if the solution meant a serious overhaul to the core of
their network?
As we will see, the ISPs that chose to migrate to an ATM core thrived and continued to
experience growth. Meanwhile, the ISPs that remained with a traditional router core had
greater challenges to grow because of the late delivery and poor performance of OC-3 SONET
interfaces for routers. In the next several sections, we’ll discuss the advantages and
disadvantages of each of these choices.
Metric-Based Traffic Control in a Routed Core

As discussed earlier, routing metric manipulation provided a basic tool for traffic control in the
early 1990s. However, as the magnitude and intricacy of carrier networks increased,
metric-based traffic control became more and more complicated to the point where it was
simply not a viable option. Network administrators could still adjust link metrics to avoid
congestion, but it became more difficult to ensure that a metric adjustment in one part of an
enormous network didn’t create a new problem in another part of the network.
Absence of “Traffic Engineering” across a Routed Core

If the only method of traffic control is to manipulate IGP metrics, it is possible for some of a
network’s links to be lightly used and other links heavily congested. This state is not cost
effective for the ISP because all trunks cost money even if they are underutilized.
Figure 8 represents the network topology for a simulated ISP operating in the United States.
There are several potential paths between the San Francisco POP and the Washington, DC POP.
Assume that the shortest path selected by the routing protocol for traffic between San
Francisco and Washington, DC is the SF-to-Chicago-to-DC route. Also assume that there is a
large amount of traffic going from San Francisco to Chicago and also a large amount of traffic
going from Chicago to Washington, DC. The result of this is that the large amount of traffic
going from San Francisco to Washington, DC has to compete against both the San
Francisco-to-Chicago and Chicago-to-Washington, DC traffic. However, if the network is only
capable of selecting links based on the IGP metrics, situations like this can often occur. Reliance
on IGP metrics creates paths that become traffic magnets. The result is congestion and poor
performance that does not exploit the economies of the bandwidth that has been provisioned
across the entire WAN.

Figure 8: Example ISP Network Topology
Salt Lake Chicago Detroit

New
York
San
Francisco Washington
Denver
D.C.
Atlanta
New
Phoenix Orleans
Dallas
IGP shortest path route S.F. to D.C.
Advantages and Disadvantages of a Routed Core

There are a number of benefits gained by remaining with a routed core when compared to
migrating to an ATM-based core:
In a routed core, the physical topology and the logical topology are identical. This
eliminates the “n-squared” problem associated with ATM networks. This “n-squared”
problem, discussed in the next section, is manifest in the complexity of adding new edge
nodes and the stress that a full-mesh topology places on routing protocols.
There is no cell-tax in a routed core. If you assume 20% overhead for ATM when factoring
in framing and realistic distribution of packets sizes, this means that on a 155-Mbps OC-3
link, 124 Mbps is available for data while 31Mbps is consumed by the ATM overhead.
However, if you consider a 2.488-Gbps OC-48 link, 1.990 Gbps is available for data and 498
Mbps is required for the ATM overhead (almost a full OC-12!). The lack of a cell tax in a
routed core means that the provisioned bandwidth is used much more efficiently.
Routed cores, by virtue of their connectionless operation, are more resilient in failure
modes. In an ATM circuit-based network, backup Permanent Virtual Circuits (PVCs) must
be designed and installed in the switches before a failure occurs. Because failures have the
potential of occurring at any point in a network, it is extremely difficult to design secondary
PVCs that can provide resiliency as well as IP routing inherently provides.
Despite these advantages, traditional routed cores have a number of significant disadvantages:
In a routed core, the traffic load is not equally distributed across the network's links causing
inefficient use of network resources. Some of the links can become congested, while other
links remain underutilized. This may be satisfactory in a sparsely connected network, but
in a richly connected network it is necessary to control the paths that traffic takes in order to
load the links relatively equally.
Metric-based traffic control does not offer an adequate solution to perform traffic
engineering. As ISP networks become more richly connected (that is, bigger, more thickly
meshed, and more redundant), it is difficult to ensure that a metric adjustment in one part
of the network doesn’t cause problems in another part of the network.

PVC-Based Traffic Control in an ATM Core

When IP runs over an ATM network, routers circle the edge of the ATM cloud. Each router
communicates with every other router by a set of PVCs that are configured across the ATM
physical topology. The routers do not have direct access to information concerning the physical
topology of the underlying network. The routers have knowledge only of the individual PVCs
that appear to them as simple point-to-point circuits between two routers. Figure 9 illustrates
how the physical topology across the ATM core differs from the logical topology across the
ATM core.
Figure 9: ATM Physical vs. Logical Topology
Physical Topology Logical Topology
S
R1
R1 S S
R3
S R3
S S S
R2
R2
PVC #1 PVC #2 PVC #3
Traffic Engineering across an ATM Core

For an ISP with an ATM core, the paths that the PVCs take through the network are typically
calculated by an off-line configuration utility. Some ATM switch vendors offer proprietary
techniques for routing PVCs on-line while taking some traffic engineering concerns into
account. However, these features are immature, and an ISP frequently has to resort to full
off-line path calculation. After the PVC mesh has been calculated, the supporting
configurations are downloaded into the routers and the ATM switches to implement the
full-mesh logical topology.
For some ISPs, each router not only participates in a full-mesh of PVCs with the other routers,
but also participates in a full-mesh of backup PVCs with every other router. Figure 10 depicts
the logical topology for an ISP network with an ATM core. Note that only the primary PVCs
are illustrated, not the secondary PVCs.

Figure 10: Logical ISP Topology over an ATM Core
New York
Chicago
Router
Router
ATM
Router Router
San Francisco Washington D.C.
Core
Router
Dallas
ATM PVCs provide a tool for supporting precision traffic engineering. The ISP determines the
path for the PVCs based on measured traffic patterns so that traffic flows are distributed across
different physical links. Each PVC is provisioned so that it is able to accommodate the
anticipated load. As the network’s traffic matrix evolves over time, the underlying physical
path supporting a particular PVC can be modified to accommodate shifting traffic loads across
the physical links.
After the PVCs are installed in the switched infrastructure, they are merged into the IP
network by running the IGP across each PVC. Between any two routers, the IGP metric for the
primary PVC is set such that it is more preferred than the backup PVC. This guarantees that
the backup PVC is used only when the primary PVC is not available.
The “N-Squared” Problem over ATM Cores

One of ATM’s limitations is that it requires a full-mesh overlay of PVCs to provide Layer 3
connectivity. This full-mesh of PVCs is the source of the “n-squared” problem. As we will see,
the “n-squared” effect makes it laborious to add new routers to the network and places
excessive stress on routing protocols.
Figure 11 illustrates how the “n-squared” problem is exhibited by the requirement to increase
the number of PVCs when a new router is added to the network. For example, when growing
the network from five to six routers, the ISP is required to increase the number of PVCs from 20
to 30. The addition of a single new router requires ten additional PVCs. Naturally, the new
PVCs need to be positioned across the physical topology so that they have minimal impact on
the existing PVCs. The task of adding a new router becomes even more challenging when the
number of routers increases from 50 to 51. This requires the addition of 100 new PVCs.

Figure 11: “N-squared” Problem and PVC Growth
5 Border Routers 6 Border Routers
5(4) = 20 6(5) = 30
The “n-squared” problem is also evidenced by the stress that a full-mesh of PVCs places on
routing protocols. Routing with a full-mesh of PVCs works over smaller networks. However,
with large networks there are significant scaling problems. The flooding of LSPs becomes
inefficient, each router has too many adjacencies with logical neighbors, and the Dijkstra
calculation becomes inefficient because of the large number of logical links.
Advantages and Disadvantages of an ATM Core

Despite the “n-squared” problem, there are a number of advantages to deploying an
ATM-based core in an ISP network:
An ATM-based core fully supports traffic engineering via PVC configuration. This permits
the ISP to precisely distribute traffic across all of their links so the trunks are evenly used.
This eliminates the traffic magnet effect of least-cost routing, which creates overutilized and
underutilized links. Traffic engineering makes the ISP more competitive within its market,
permitting it to provide lower costs and better service to its customers.
In an ATM-based core, the per-PVC statistics provided by the switches facilitate the
monitoring of traffic patterns. Network designers provision each PVC to support specific
traffic-engineering objectives. They constantly monitor traffic on the PVCs. If a given PVC
begins to experience congestion, the ISP has all the information it needs to remedy the
situation.
Despite the significant advantage of supporting traffic engineering, ATM-based cores still have
a number of substantial limitations:
The full-mesh of ATM PVCs exhibits the “n-squared” problem.
The ATM cell tax can consume a significant amount of bandwidth. As discussed earlier, the
cell tax on an OC-48 can be as much as a full OC-12. The elimination of the cell tax in a
routed core means that bandwidth is used as efficiently as possible and not wasted on
unnecessary overhead.
ATM-based cores, by virtue of their connection-oriented operation, are less resilient in
failure modes. In a routed core, alternate paths are calculated on demand whenever a link
or peer fails. In an ATM-based core, backup paths have to be calculated in advance and
then installed in the switches to provide an immediate backup capability.

ATM-based cores require the management of two different networks, an ATM

infrastructure and a logical IP overlay. The task of managing any given network has a
specific amount of associated cost. By running an IP network over an ATM network, an ISP
doubles its overhead because it needs to manage two separate networks. Also, routing and
traffic engineering occur on different sets of boxes (that is, routing happens on the routers
and traffic engineering happens on the ATM switches). As a result, there are two
configuration processes to design, operate, and debug.
Traffic Statistics Support Traffic Engineering

Growing a network requires knowing, for each entry point in the network, how much traffic
goes to each exit point. The ability of an ATM switch to provide per-PVC statistics simplifies
the task of gathering the information needed to make intelligent traffic engineering decisions.
The statistics provide the ISP with visibility into the amount of traffic traversing each of the
PVCs, supplying information so the ISP can determine which PVCs are experiencing traffic
growth.
Building a traffic matrix is more difficult with a routed core, because traffic counts on backbone
trunks don’t separate traffic that is either entering or exiting the network at a given POP from
traffic that is transiting the POP. One possible way to collect data in a routed core is traffic
sampling (for example, capture 1 out of every 100 packets). If you can capture a statistically
significant portion, this might be adequate, but it’s extremely difficult to accomplish at OC-48
rates. Proprietary techniques such as flow switching provide a bit more information about a
routed core, but they still require a fair amount of off-line analysis and their ability to scale
towards OC-48 rates is doubtful.
Collecting statistics and traffic engineering are separate issues. However, if you consider traffic
engineering as part of a closed-loop feedback system, traffic statistics provide the raw
information allowing the ISP to accurately provision its network links. In an ATM core,
network operations provision each PVC to support specific traffic-engineering requirements.
They constantly monitor traffic on the PVC, and if a particular link begins to experience
congestion, they can modify the physical path the PVC takes across the ATM infrastructure.
After the problem has been resolved, they continue to monitor the PVC in anticipation of the
next bottleneck.
The Multiprotocol Label Switching (MPLS) Solution

Table 1 provides a summary of the benefits and limitations of traditional routed cores and
ATM-based cores. As we enter the age of the optical Internet, any emerging traffic engineering
solution should combine the advantages of routed cores and ATM-based cores while
eliminating their disadvantages.

Table 1: Traditional Router Cores vs. ATM Cores
Advantages Disadvantages
Traditional Router Physical topology matches Under-utilized links

Cores logical topology Over-utilized links
No "n-squared" problem Engineering by routing metrics
No cell tax is complex
Resilient in failure modes
Traffic engineering supported ATM cell tax

ATM Cores via PVC configuration Full mesh of ATM PVCs;
Per-PVC statistics monitor "n-squared" problem
traffic patterns and provide Less resilient in failure modes
feedback to traffic engineering Requires management of two
separate networks
Back in 1994, ISPs were simply looking to obtain more bandwidth so they could handle
increasing amounts of network traffic. ISPs that decided to pursue an ATM-based core quickly
discovered that the ATM core provided them with two critical features: the ability to perform
traffic engineering to equalize the traffic loads across the network, and per-PVC statistics to
count traffic. ISPs have became very comfortable with the level of control that ATM-based
cores provide when compared to traditional routed cores. Today, ISPs are not willing to give up
the control that ATM provides. Despite the numerous limitation of ATM (that is, the cell tax,
the “n-squared” problem, and the cost of managing two separate networks), ISPs understand
that they require traffic-engineering capabilities similar to ATM to successfully run their
networks.
Juniper Networks believes that Multiprotocol Label Switching (MPLS) is the emerging solution
to support traffic engineering in large service provider networks. It combines the advantages
of router-based and ATM-based cores, while eliminating the disadvantages. A few of the
benefits offered by MPLS include:
Ability to precisely control the use of valuable resources during periods of rapid growth
Stability under congestion and failure modes
Providing ISPs the foundation for value-added services
This is an area where Juniper Networks has been extremely proactive through its efforts with
the MPLS and RSVP Working Groups of the IETF. Juniper Networks has also gained
considerable practical experience with MPLS based on field trials with several major ISPs.
Multiprotocol Label Switching (MPLS)

The key feature provided by MPLS is the ability to provide label switched paths (LSPs), which
are similar to PVCs in ATM and Frame Relay networks. An LSP is created by the concatenation
of one or more label switched hops, allowing a packet to be forwarded from one label
switching router (LSR) to another LSR across the ISP network (Figure 12). An LSR is a router
that supports MPLS.

Figure 12: Label Switched Path (LSP)
Salt Lake Chicago Detroit

New
York
San
Francisco Washington
Denver
D.C.
Atlanta
New
Phoenix Orleans
Dallas
LSP from San Francisco to Washington D.C.

Shortest path from San Francisco to Washington D.C. calculated by IGP
An LSR that receives an IP packet can choose to forward it along an LSP by wrapping an MPLS
header around the packet and forwarding it to another LSR. The labeled packet will be
forwarded along the LSP by each LSR until it reaches the end of the LSP, at which time the
MPLS header will be removed and the packet will be forwarded based on Layer 3 information
like the IP destination address. The important point here is that the path of the LSP is not
limited to what the IGP would choose as the shortest path to reach the destination IP address.
MPLS Packet Forwarding Mechanism: Label Swapping

The forwarding process of each LSR is based on the concept of “label swapping.” The labels are
bound to IP prefixes and are link-local. When a packet containing a label arrives at an LSR, the
LSR examines the label and uses it as an index into its forwarding table. Each entry in the
forwarding table contains an inbound label that is mapped to a set of forwarding information
that is applied to all packets that carry the same inbound label (Table 2).
Table 2: Label-switching Forwarding Table
In Interface In Label Out Interface Out Label
2 25 5 185
2 256 3 735
Figure 13 depicts the operation of the label-swapping algorithm utilized by an LSR. When a
packet is received on Interface #4 of the LSR with a Label = 36, the LSR uses the outbound set
of information to forward the frame. In this example, the LSR builds a new packet with a Label
= 19 and forwards the packet over Interface #5.

Figure 13: A Label Switching Router (LSR) Forwards Packets
In In Out Out
Interface Label Interface Label
4 36 5 19
MPLS and Packet-Forwarding Performance

One of the great myths about MPLS is that it significantly enhances the forwarding
performance of routers. Recall that IP forwarding is based on a longest-match lookup, while
MPLS is based on an exact match lookup (that is, the same type of lookup as ATM). It has
historically been a fact that ATM switches could perform faster fixed-length lookups in
hardware than routers could perform longest-match lookups in software. However, recent
advances in silicon technology allow ASIC-based route lookup engines to run just as fast as
ATM VPI/VCI lookup engines. Because routers can now forward packets at line rates just like
an ATM switch can forward cells, forwarding performance is no longer an issue. So the true
benefit of MPLS is the increased traffic-engineering capabilities that it offers.
Traffic Engineering with MPLS

Traffic enters and exits a backbone network from the network’s border routers. In the context
of traffic engineering, the border routers are called the ingress and egress points to and from
the network. Traffic engineering is accomplished with MPLS by establishing LSPs between
ingress points and egress points (Figure 14).

Figure 14: LSP Between an Ingress LSR and an Egress LSR
Recall that the essence of traffic engineering is mapping traffic onto a physical topology. This
means that the crux of the issue for doing traffic engineering with MPLS is determining the
path for LSPs. The Juniper Networks implementation of MPLS supports a number of different
ways to route an LSP:
Calculate the full path for the LSP off-line and statically configure all LSRs in the LSP with
the necessary forwarding state. This is analogous to how some ISPs are currently using
ATM.
Calculate the full path for the LSP off-line and statically configure the head-end LSR with
the full path. The head-end LSR then uses the Resource Reservation Setup Protocol (RSVP)
as a dynamic signaling protocol to install forwarding state in each LSR. Note that RSVP is
being used only to install the forwarding state, and it does not reserve bandwidth or
provide any assurance of minimal delay or jitter. The Juniper Networks engineers were
involved in specifying the new Label Object, Explicit Route Object, and Record Route
Object for RSVP that allow it to operate as an LSP set-up protocol.
Calculate a partial path for the LSP off-line and statically configure the head-end LSR with
a subset of the LSRs in the path. The partial path that is specified can include any
combination of strict and loose routes. For example, imagine an ISP has a topology that
includes two east-west paths across the country: one in the north through Chicago and one
in the south through Dallas. Now imagine that the ISP wants to establish an LSP between a
router in New York and a router in San Francisco. The ISP could configure the partial path
for the LSP to include a single loose-routed hop of an LSR in Dallas and the result is that the
LSP will be routed along the southern path. The head-end LSR uses RSVP to install the
forwarding state along the LSP just as above.
Configure the head-end LSR with just the identification of the tail-end LSR. In this case,
normal IP routing is used to determine the path of the LSP. This configuration doesn’t
provide any value in terms of traffic engineering, though the configuration is easy and it
might be useful in situations where services like Virtual Private Networks (VPNs) are
needed.
In all these cases, any number of LSPs can be specified as backups for the primary LSP. If a
circuit on which the primary LSP is routed fails, the head-end LSR will notice because it will
stop hearing RSVP messages from the remote end. If this happens, the head-end LSR can call
on RSVP to create forwarding state for one of the backup LSPs.

The Future of MPLS: Constraint-Based Routing

The use of LSPs with RSVP provides an ideal paradigm for constraint-based routing. In
constraint-based routing, the network administrator configures constraints for traffic
exchanges between routers and then the network itself determines a path that meets those
constraints. Juniper Networks plans to extend the MPLS implementation to support
constraint-based routing so that the network itself can participate in traffic engineering. This
will allow the head-end LSR to calculate the entire LSP based on certain constraints and initiate
signaling across the network.
An example of a constraint is bandwidth. For example, assume that a particular router in New
York needs to send 30 Mbps to a particular router in San Francisco and 20 Mbps to a particular
router in Los Angeles. Another example of a constraint is class of service (CoS). For example, a
particular link between a pair of routers may be dedicated exclusively to “premium”
customers.
A key feature required to extend MPLS in this manner is bandwidth reservation. Assume that
the LSRs in the network have the ability to request bandwidth, respond to such requests, and
advertise the current state of the allocation of their bandwidth. In a network supporting such
features, the establishment of LSPs could be performed by negotiating with the network itself
and could take into account bandwidth on a given trunk already committed to flows between a
given set of ingress and egress points. The advertisement of circuit bandwidths, as well as the
amount of that bandwidth already committed to flows, could be added to IS-IS and OSPF with
new Type-Length-Value attributes.
Some of the benefits of constraint-based routing include:
Constraint-based routing achieves the same control as more-manual traffic engineering but
with less human intervention, because the network itself participates in LSP calculation.
The dynamic distribution of information in the IGP allows traffic engineering to react
quickly to changes.
Constraint-based routing allows faster failover, thus reducing the effective convergence
time.
MPLS Benefits
Previously, it was suggested that any emerging solution providing traffic engineering across
the optical Internet must combine the advantages of ATM and routed cores while eliminating
the disadvantages. Let’s conclude this section by examining how well MPLS meets this
challenge.
An MPLS core fully supports traffic engineering via LSP configuration. This permits the ISP
to precisely distribute traffic across all of their links so the trunks are evenly used.
In an MPLS core, the per-LSP statistics reported by the LSRs provide exactly the type of
information required for configuring new traffic engineering paths and also for deploying
new physical topologies.
In an MPLS core, the physical topology and the logical topology are identical. This
eliminates the “n-squared” problem associated with ATM networks.
The lack of a cell tax in an MPLS core means that the provisioned bandwidth is used much
more efficiently than in an ATM core.

An MPLS core converges the Layer 2 and Layer 3 networks required in an ATM-based core.
The management of a single network reduces costs, and permits routing and traffic
engineering to occur on the same platform. This simplifies the design, configuration,
operation, and debugging of the entire network.
MPLS support for a dynamic protocol, such as RSVP, simplifies the deployment of traffic
engineered LSPs across the network.
MPLS provides the foundation for ISPs to offer value-added services.
Future MPLS support for constraint-based routing achieves the same control as
more-manual traffic engineering but with less human intervention because the network
itself participates in LSP calculation.
User Interface
The user interface allows network personnel to interact with and configure JUNOS. Juniper
Networks has taken extraordinary effort to build an efficient human interface that minimizes
the chance of configuration errors.
Command-Line Interface (CLI)

By default, network administrators interact with JUNOS through the command-line interface
(CLI). A CLI starts when a user logs on to the system. The CLI may be accessed several ways as
illustrated in Figure 15.
Figure 15: Accessing the Command-Line Interface
Telnet/SSH
In-Band
Production
Interface
JUNOS Software
10/100
Serial Serial
Ethernet
Mgmt. Console Aux
Interface Interface Interface
Out-of-Band
Telnet/SSH Terminal Modem
The CLI permits the performance of various tasks including configuring the JUNOS system,
restarting system processes, and monitoring the operation of the routing protocols. The CLI
supports consistent command names, on-line help, and a command-completion feature.

Group, Commit, and Rollback Capabilities

Assume that an operator changes the system’s configuration and signals the software to make
the new configuration effective by committing it. The JUNOS software has the ability to look at
its existing configuration, examine the new configuration, and then only make the changes
necessary to achieve the desired state. As part of the commit process, the configuration is
checked for semantic errors. If the configuration is consistent, the configuration is activated
and the software processes running on the system—including the routing protocols, interfaces,
SNMP, and chassis processes—read the new configuration information and change their
operation to match the new configuration. In one atomic operation the software is given the
order to reconfigure itself.
This is totally unlike any legacy router configuration process. With legacy routing systems, a
user enters the configuration mode, types in a single command, and then presses the <Enter>
key. Pressing the <Enter> key commits the last line entered. This model requires that complex
changes take place one step at a time rather than as a single configuration transaction. A
step-by-step configuration model can result in temporary routing misconfigurations that lead
to network instabilities.
For example, assume that a network administrator wants to add a new BGP peer but only
wants to import specific routes from this peer based on a routing policy. With legacy systems,
the administrator needs to perform several independent steps: define a policy, create the new
peer, and then apply the routing policy to the new peer. With the step-by-step model, it is
possible to create the BGP peer, establish the BGP session, and initiate the exchange of routing
information—all before the policy has been applied to the peer. In the legacy model, the only
way around this challenge is to exit the configuration mode and quickly reset the peering
session causing the session to be re-established. Meanwhile, who can determine what routing
information has been advertised across the service provider’s network!
A very common practice is for an operator to cut-and-paste a configuration from one window
to another window on the network management station. Assume that an operator does this,
but in the 10 lines that are cut the 7th line contains a syntax error. If lines 8, 9, 10 were
dependent on line 7, who can determine the exact configuration state of the router? With the
JUNOS software, entering and committing the 10 lines will result in a syntax error for line 7.
None of the 10 lines of configuration changes are committed due to the syntax error contained
in line 7. Juniper’s implementation of the group/commit feature allows the operator to go back
to the editor, fix the syntax error, and then recommit the entire set of configuration changes.
Juniper Networks also implements a rollback feature that permits a user to return to a
previously configured state. Assume that an operator makes a configuration change that
causes the loss of reachability information across the network. The JUNOS software allows the
operator to quickly rollback to a previous configuration that provides a stable network state.
Configuration Change Control

Configuration change control is designed to provide a level of control when multiple users are
given access to a system. In the process of committing configuration changes, users are given
the opportunity to document the changes made. This allows other users to view a history of
changes and the specific individual responsible for those edits. They could even view
differences against previous versions of the configuration to determine exactly what has been
altered, who made the change, and when.
Configuration change control is an extremely powerful tool when attempting to resolve
complex failure situations. Assume that a network administrator knows that the router
configuration was functional at 2 p.m., but that it began to fail at 2:37 p.m. The JUNOS

software makes it possible for weeks of configuration changes to be archived, thus providing
the ability to track the history of a router’s configuration. Legacy routing systems simply log
the fact that the configuration was updated by a specific user. However, they do not provide
the tools to identify the specific modifications or the ability to return to a stable configuration.
Numerous User Access Levels

The JUNOS software assigns each command to one of several different categories. This allows
the network administrator to define a number of different user classes, allocate one or more of
the categories to each user class, and then assign a specific user to one of the administrator
defined user classes. For example, someone working in the NOC could be assigned to the
“tech-user” class and be permitted to show and reset the configuration, but not allowed to
manage interfaces, routing, or user accounts. Likewise, the system manager may be the only
user assigned to the “super-user” class that is allowed complete access to the entire system.
The JUNOS software allows system administrators to establish any number of user groups,
and provide each user group with a different level of access to the system.
Typically, legacy routing systems only offer two levels of system access. With low-level access,
a user can show individual parameters, but is not allowed to modify parameters or show the
entire system configuration. With high-level access, a user is granted complete access to the
entire system. Legacy systems only provide the administrator two possible choices: be
extremely restrictive which limits the ability of operators to solve problems, or be overly
permissive which offers its own set of potential hazards.
Alternate User Interfaces

The default user interface is the CLI that starts automatically when the user logs in to the
system. The CLI communicates with the Management Process that is responsible for enabling
the configuration of the entire system. The Management Process interacts with the CLI to
provide access to the other subsystems and to the database that contains all configuration
parameters (for example, interface configurations, routing protocol configurations, routing
policy, traffic filters, and user access privileges). The relationship of the Management Process to
the rest of the Juniper Networks system is illustrated in Figure 16.
Figure 16: Alternate User Interfaces to JUNOS
CLI Script
Database
Management
Process
Network Interfaces
Routing Process
Process
Kernel

In the Juniper Networks design, the CLI communicates with the Management Process through
an exchange of well-formatted command strings. This arrangement permits the CLI to be
relatively simple because all the intelligence resides in the Management Process. The exchange
of these messages allows the CLI to understand which commands the JUNOS software
considers valid and invalid. If the CLI attempts to do something that the Management Process
considers incorrect, the Management Process will inform the CLI. However, there is no reason
that a Web browser or a customer written script could not replace the CLI. The only
prerequisite is that the alternative user interface “speak” the strings that the Management
Process does.
With legacy routing systems, the CLI is the only interface that supports device configuration. If
a user desires to write a script, the script must be written so that it speaks to the CLI.
Experience has shown that one of the most difficult tasks to automate against is one that was
originally designed to be interactive. For example, a typical CLI presents the script with a
prompt; the script enters a command; signals the <Enter> key; and then the system spews
output that must be parsed looking for a prompt before the next command can be entered. In
the JUNOS software, the output from the Management Process is ideal for parsing by a
computer, as opposed to a legacy CLI that is optimized for humans to read. Juniper Networks
provides not only a powerful CLI for humans, but also the Management Process that can be
leveraged to support other configuration models.
Support for ASCII Configuration Files

Juniper Networks does not implement binary configuration files that limit the use of text
editors and require a specialized operator interface. The system configuration database or
portions of the database are represented in a flat ASCII file that may be modified and then
re-imported into the database system. The configuration system provides both import and
export capabilities. These functions respect the permission capability matrix so that a user may
only export the portions of the system configuration that they are allowed to view. ASCII files
provide the flexibility required in large ISP environments for the off-line management of
hundreds of routers on a daily basis.
System Security
Strong security is a must for any system running in the core of an ISP network. The number of
Internet threats that the average customer and ISP are exposed to have been constantly
growing. As a result, network systems must support inherent security precautions that
safeguard the operation, service, and functionality of all supported services. This section
provides a brief discussion of just some of the security features supported by the JUNOS
software.
Secure Shell (SSH) Support

SSH provides a service similar to Telnet, though with SSH the data going across the network is
encrypted. JUNOS allows users to SSH into the router to access the command-line interface
(CLI). A hacker, snooping on the session, will not be able to understand an intercepted
message or read passwords as they go across the network.

Denial-of-Service Attacks
Denial-of-service attacks are those which prevent access by authorized users. The attacker
floods the system with traffic that blocks entry by others or consumes all available resources
such as memory and CPU. The JUNOS software is designed so that traffic that is required to go
to the Routing Engine (such as pings, Telnet, routing protocol updates, and keepalives) is
categorized and placed into different priority queues. Routing protocol updates and link-level
keepalives receive the highest priority. This enhances network stability because routing
protocol adjacencies and line protocols should never go down regardless of the load on the
system.
MD5 Protects BGP Sessions

The JUNOS software supports the TCP MD5 authentication option for BGP sessions. MD5 is a
message digest (like a checksum with a cryptographic component) that is carried as an option
in the TCP header of a BGP message. The BGP message doesn’t get encrypted, but the digest
protects the validity of the contents of each message. Each peer has a shared secret password
that is never sent across the network. The peers use this password to generate and verify the
digest.
MD5 protects against three potential types of attack. In the first type of threat, the hacker
attempts to steal service from a provider by getting the ISP to advertise the attacker’s route
without the ISP ever realizing it. The second attack involves adding routes to the ISP’s routing
table in an attempt to black-hole traffic. The final attack attempts to damage a TCP/BGP
connection and destabilize the network.
Network Management
The JUNOS software is designed with an open-systems architecture. Management of the
device is accomplished via standard tools based on the IP protocol suite. These tools include,
but are not limited to, SNMP, secured TCP connections, Telnet, FTP, ICMP, and NTP. Our
fundamental approach is to fit into the typical model that ISPs are familiar with.
Management Console
The command-line interface (CLI) is fully accessible through the management console and the
management Ethernet interface. All information and tools needed for management of the
device are available from the management console. These tools include, but are not limited to,
protocol trace logs, system availability information, configurable debugging, Telnet,
traceroute, ping, and full CLI access.
SNMP Management
SNMP is required to integrate into standards-based network management and monitoring
systems. Juniper Networks supports industry-defined standard MIBs and provides private
MIB definitions when necessary. An example of this is the Juniper Networks chassis MIB,
which describes the physical status of the system, including inventory support. When private
MIBs are defined, industry-standard conventions are used so that the MIBs can be quickly
incorporated into standards-based SNMP management systems

SNMPv1 and SNMPv2 have relatively poor security models. Security is typically controlled
through a “community string,” which is a clear-text identifier that is passed with every packet
across the network. Because this security scheme is so easy to subvert, configuration
operations and most “operator” class operations (for example, clear a routing protocol
adjacency) are not supported under SNMPv1 and SNMPv2. However, system professionals
can still access all of the statistics that are normally collected by the SNMP MIBs. Only when
SNMPv3 support is commercially available with reasonable cryptographic security will
Juniper Networks incorporate remote SNMP configuration into the JUNOS software.
JUNOS Software Delivers Internet Control and Scaling

Internet backbone providers are under constant pressure to scale their networks quickly to
unprecedented sizes. New technologies and fiber deployment, coupled with faster forwarding
engines, will make this growth possible. However, managing this growth responsibly requires
software tools to handle the operational changes of extremely large networks. These tools must
be evaluated in terms of the software architecture, routing protocols, policy definition
language, traffic engineering capabilities, user interface, system security, and network
management features. The JUNOS software has been developed specifically to meet
Internet-scale requirements in each of these essential areas. Best-in-class talent with extensive,
practical Internet experience developed the JUNOS software. More importantly, it was
designed from the very beginning with continued growth in mind.
Juniper Networks understands that meeting Internet backbone growth challenges will become
only more challenging. Providers will need new features delivered more rapidly and reliably
than ever before. Development talent, extensive experience, and an innovative JUNOS
software design combine to form a reliable foundation on which ISPs can base new growth.
Copyright © 2000, Juniper Networks, Inc. All rights reserved. Juniper Networks is a registered trademark of Juniper Networks, Inc. JUNOS,
M20, and M40 are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks
may be the property of their respective owners. All specifications are subject to change without notice. Printed in USA.

Junos PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Junos PDF

Загружено:

Авторское право:

Доступные форматы

White Paper

Optimizing Routing Software for Reliable

Juniper Networks, Inc.

Part Number : 200003-002

Copyright © 2000, Juniper Networks, Inc.

Copyright © 2000, Juniper Networks, Inc.

Copyright © 2000, Juniper Networks, Inc.

Internet Routing Software Architecture

Copyright © 2000, Juniper Networks, Inc. 5

Limitations of Legacy Router Software Architectures

Figure 1: Typical Legacy Routing Software Architecture

6 Copyright © 2000, Juniper Networks, Inc.

JUNOS Origins in FreeBSD

Copyright © 2000, Juniper Networks, Inc. 7

Juniper Networks Software Architecture

Figure 2: Routing Engine and Packet Forwarding Engine

Packet Forwarding Engine

Packet Forwarding Engine

8 Copyright © 2000, Juniper Networks, Inc.

Figure 3: Conceptual View of JUNOS Software Elements

Benefits of the JUNOS Architecture

Protected Memory Ensures Operational Reliability

Designed Specifically for ISP Networks

Enhanced Network Stability

Copyright © 2000, Juniper Networks, Inc. 9

Industrial-Strength Routing Protocols

Design for Stability

10 Copyright © 2000, Juniper Networks, Inc.

Design for Scalability

JUNOS Routing Protocol Implementations

Interior Gateway Protocols: IS-IS and OSPF

Exterior Gateway Protocols: BGP-4

Multicast Routing Protocols

Copyright © 2000, Juniper Networks, Inc. 11

Juniper Networks Engineering Staff

Routing Policy Definition Language

12 Copyright © 2000, Juniper Networks, Inc.

Figure 4: Acceptance and Distribution of Routing Information

Figure 5: Policy Filtering Example

JUNOS Policy Definition Language

Copyright © 2000, Juniper Networks, Inc. 13

programming language, it is very general in nature, permitting it to be extended over time by

Optimizing the Search

Figure 6: A Linear Search vs. a Tree Search

Linear Search (O(n))

Testing Policy Configurations

14 Copyright © 2000, Juniper Networks, Inc.

Evolution of Internet Backbone Traffic Control

Figure 7: Metric Based Traffic Control

ISPs Decide Between a Routed Core and an ATM Core

Copyright © 2000, Juniper Networks, Inc. 15

Metric-Based Traffic Control in a Routed Core

Absence of “Traffic Engineering” across a Routed Core

16 Copyright © 2000, Juniper Networks, Inc.

Figure 8: Example ISP Network Topology

Salt Lake Chicago Detroit

IGP shortest path route S.F. to D.C.

Advantages and Disadvantages of a Routed Core

Copyright © 2000, Juniper Networks, Inc. 17

PVC-Based Traffic Control in an ATM Core

Figure 9: ATM Physical vs. Logical Topology

Physical Topology Logical Topology

PVC #1 PVC #2 PVC #3