-
Notifications
You must be signed in to change notification settings - Fork 0
/
impl.html
408 lines (295 loc) · 18.4 KB
/
impl.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
<!DOCTYPE html>
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Chapter 6: Exemplar Implementation — 5G Mobile Networks: A Systems Approach Version 0.1 documentation</title>
<link rel="shortcut icon" href="static/bridge.ico"/>
<script type="text/javascript" src="static/js/modernizr.min.js"></script>
<script type="text/javascript" id="documentation_options" data-url_root="./" src="static/documentation_options.js"></script>
<script type="text/javascript" src="static/jquery.js"></script>
<script type="text/javascript" src="static/underscore.js"></script>
<script type="text/javascript" src="static/doctools.js"></script>
<script type="text/javascript" src="static/language_data.js"></script>
<script async="async" type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.5/latest.js?config=TeX-AMS-MML_HTMLorMML"></script>
<script type="text/javascript" src="static/js/theme.js"></script>
<link rel="stylesheet" href="static/css/theme.css" type="text/css" />
<link rel="stylesheet" href="static/pygments.css" type="text/css" />
<link rel="stylesheet" href="static/css/rtd_theme_mods.css" type="text/css" />
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="Chapter 7: Cloudification of Access" href="cloud.html" />
<link rel="prev" title="Chapter 5: Advanced Capabilities" href="disaggregate.html" />
</head>
<body class="wy-body-for-nav">
<div class="wy-grid-for-nav">
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
<div class="wy-side-scroll">
<div class="wy-side-nav-search" >
<a href="index.html" class="icon icon-home"> 5G Mobile Networks: A Systems Approach
</a>
<div class="version">
Version 0.1
</div>
<div role="search">
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
<input type="text" name="q" placeholder="Search docs" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div>
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
<p class="caption"><span class="caption-text">Table of Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="preface.html">Preface</a></li>
<li class="toctree-l1"><a class="reference internal" href="intro.html">Chapter 1: Introduction</a></li>
<li class="toctree-l1"><a class="reference internal" href="primer.html">Chapter 2: Radio Transmission</a></li>
<li class="toctree-l1"><a class="reference internal" href="arch.html">Chapter 3: Basic Architecture</a></li>
<li class="toctree-l1"><a class="reference internal" href="ran.html">Chapter 4: RAN Internals</a></li>
<li class="toctree-l1"><a class="reference internal" href="disaggregate.html">Chapter 5: Advanced Capabilities</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">Chapter 6: Exemplar Implementation</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#framework">6.1 Framework</a></li>
<li class="toctree-l2"><a class="reference internal" href="#platform-components">6.2 Platform Components</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="cloud.html">Chapter 7: Cloudification of Access</a></li>
<li class="toctree-l1"><a class="reference internal" href="README.html">About This Book</a></li>
</ul>
</div>
</div>
</nav>
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
<nav class="wy-nav-top" aria-label="top navigation">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="index.html">5G Mobile Networks: A Systems Approach</a>
</nav>
<div class="wy-nav-content">
<div class="rst-content">
<div role="navigation" aria-label="breadcrumbs navigation">
<ul class="wy-breadcrumbs">
<li><a href="index.html">Docs</a> »</li>
<li>Chapter 6: Exemplar Implementation</li>
<li class="wy-breadcrumbs-aside">
<a href="_sources/impl.rst.txt" rel="nofollow"> View page source</a>
</li>
</ul>
<hr/>
</div>
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
<div itemprop="articleBody">
<div class="section" id="chapter-6-exemplar-implementation">
<h1>Chapter 6: Exemplar Implementation<a class="headerlink" href="#chapter-6-exemplar-implementation" title="Permalink to this headline">¶</a></h1>
<p>The steps we’ve taken in the previous chapters to virtualize,
disaggregate, optimize, distribute, and slice the cellular network not
only help us understand the inner-workings of 5G, but they are also
necessary to reduce the entirety of the 5G cellular network to practice.
The goal is an implementation, which by definition, forces us to make
specific engineering choices. This chapter describes one set of
engineering choices that results in a running system. It should be
interpreted as an exemplar, for the sake of completeness, but not the
only possibility.</p>
<p>The system we describe is called CORD, which you will recall from the
Introduction is an acronym (<strong>C</strong>entral <strong>O</strong>ffice
<strong>R</strong>e-architected as a <strong>D</strong>atacenter). More concretely, CORD is a
blueprint for building a 5G deployment from commodity hardware and a
collection of open source software components. We call this
hardware/software combination a CORD POD, where the idea is to deploy a
POD at each edge site that is part of a cellular network. The following
describes CORD in terms of a set of engineering decisions. It is not a
substitute for detailed documentation for installing, developing, and
operating CORD, which can be found elsewhere:
<a class="reference external" href="https://guide.opencord.org">https://guide.opencord.org</a>.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">As discussed in the Introduction, even though CORD includes “Central
Office” in its name, a CORD POD is a general design, and not strictly
limited to being deployed in a conventional Central Office.</p>
</div>
<p>Before getting into the specifics, it is important to understand that
CORD is a work-in-progress, with a sizable open source community
contributing to its code base. Many of the components are quite mature,
and currently running in operator trials and production networks. Others
(largely corresponding to the advanced capabilities described in the
previous chapter) are prototypes that run in “demonstration mode,” but
are not yet complete enough to be included in official releases. Also,
as outlined in the earlier discussion on deployment options, CORD starts
with a production-quality EPC that is being incrementally evolved into
its 5G counterpart. (This chapter uses the EPC-specific components for
illustrative purposes.)</p>
<div class="section" id="framework">
<h2>6.1 Framework<a class="headerlink" href="#framework" title="Permalink to this headline">¶</a></h2>
<p><a class="reference internal" href="#fig-cord"><span class="std std-ref">Figure 6.1</span></a> gives a schematic overview of a CORD POD. It
connects downstream to a set of DUs (and associated RUs), and upstream
to the rest of the Internet. Internally, it includes a set of commodity
servers (the figure shows four racks of three servers each, but the
design accommodates anywhere from a partial rack to 16 racks) and a set
of white-box switches arranged in a leaf-spine topology (the figure
shows two leaves and two spine switches, but the design allows anywhere
from a single switch to two leaf switches per rack and as many spine
switches as necessary to provide sufficient east-to-west bandwidth).</p>
<div class="figure align-center" id="id1">
<span id="fig-cord"></span><a class="reference internal image-reference" href="_images/Slide25.png"><img alt="_images/Slide25.png" src="_images/Slide25.png" style="width: 650px;" /></a>
<p class="caption"><span class="caption-text">Figure 6.1: CORD implementation of RAN and Mobile Core.</span></p>
</div>
<p>With respect to software, <a class="reference internal" href="#fig-cord"><span class="std std-ref">Figure 6.1</span></a> shows a combination of
RAN (red) and Mobile Core (blue) components, plus the modules that
define the CORD platform (orange). We describe the platform components
later in this chapter, but you can think of them as collectively
implementing a multi-tenant cloud on top of which many different
scalable services can run. The RAN and Mobile Core are two such tenants.
The CORD platform can also host other edge services (which is one reason
CORD is built using cloud technology in the first place), but exactly
what other edge services might run on a given CORD POD is beyond the
scope of this book.</p>
<p>The RAN and Core related components are ones we’ve described in earlier
chapters. They include the Control and User planes of the CU and Mobile
Core, respectively, where to simplify the diagram, we show the SGW and
PGW merged into a single S/PGW. One aspect of Figure E that requires
further elaboration is how each of the RAN and Mobile Core components
are actually realized. There are three different manifestations of the
functional components implied by the Figure: (1) the data plane layer of
the CU-U and S/PGW-U are realized as P4 programs loaded into the
programmable switches; (2) the control plane layer of the CU-U and
S/PGW-U (as well as the Trellis platform module) are realized as control
applications loaded onto the ONOS Network OS; and the remaining
components are realized as Kubernetes-managed microservices. (Kubernetes
is implicit, and not shown in the figure.)</p>
<p>To expand on this idea, <a class="reference internal" href="#fig-ci-cd"><span class="std std-ref">Figure 6.2</span></a> gives an alternative
view of a CORD POD, abstracting away the details of <em>what</em> services it
hosts, and focusing instead on <em>how</em> those services are instantiated on
the POD. In this figure, all the functionality instantiated onto the POD
runs as a combination of Kubernetes-based microservices and ONOS-based
control applications.</p>
<div class="figure align-center" id="id2">
<span id="fig-ci-cd"></span><a class="reference internal image-reference" href="_images/Slide26.png"><img alt="_images/Slide26.png" src="_images/Slide26.png" style="width: 350px;" /></a>
<p class="caption"><span class="caption-text">Figure 6.2: Alternative view of CORD, with a CI/CD toolchain
managing the platform and set of services implemented by a
combination of ONOS-based control apps and Kubernetes-based
microservices.</span></p>
</div>
<p>When abstracted in this way, we can view a POD as including three major
subsystems:</p>
<ul class="simple">
<li><strong>Platform:</strong> The base layer common to all configurations includes
Kubernetes as the container management system and ONOS as the SDN
controller, with Stratum loaded on to each switch. Both ONOS and the
control applications it hosts run as a Kubernetes-managed
microservices.</li>
<li><strong>Profile:</strong> The deployment-specific collection of microservices and
SDN control apps that have been selected to run on a particular POD.
This is a variable and evolvable set, and it includes the control
plane and edge services described elsewhere.</li>
<li><strong>CI/CD Toolchain:</strong> Used to assemble, deploy, operate, and upgrade a
particular Platform/Profile combination. It implements a set of
processes that transforms a collection of disaggregated and
virtualized components into an operational system capable of
responding to operator directives and carrying live traffic.</li>
</ul>
<p>Although beyond the scope of this book, the CI/CD toolchain uses
standard DevOps tools to bootstrap software onto the cluster of servers
and switches, and rollout/rollback individual microservices and control
applications. It also auto-generates the Northbound Interface (NBI) that
operators use to manage the POD, based on a declarative specification of
the Profile the POD is configured to support. This NBI is sufficiently
complete to operate a CORD POD in a production environment.</p>
</div>
<div class="section" id="platform-components">
<h2>6.2 Platform Components<a class="headerlink" href="#platform-components" title="Permalink to this headline">¶</a></h2>
<p>We now return to the three platform-related components shown in <cite>Figures
:ref:`Figure 6.1 <fig-cord></cite> and <a class="reference internal" href="#fig-ci-cd"><span class="std std-ref">6.2</span></a>. Each is a
substantial open source component in its own right, but for our
purposes, it is enough to understand the role each plays in supporting
a 5G-based profile of CORD.</p>
<ul class="simple">
<li><strong>Stratum:</strong> A thin operating system that runs locally on each
white-box switch. It’s purpose is to provide a hardware-independent
interface for managing and programming the switches in CORD. This
includes using <em>P4</em> to define the forwarding behavior of the switch’s
forwarding pipeline (think of this program as a contract between the
control and data planes), and <em>P4Runtime</em> to control that forwarding
contract at runtime.</li>
<li><strong>ONOS:</strong> A Network Operating System used to configure and control a
network of programmable white-box switches. It runs off-switch as a
logically centralized SDN controller, and hosts a collection of SDN
control applications, each of which controls some aspect of the
underlying network. Because it is logically centralized, ONOS is
designed to be highly available and to have scalable performance.</li>
<li><strong>Trellis:</strong> An ONOS-hosted SDN control application that implements a
leaf-spine fabric on a network of white-box switches. It implements
the control plane for several features, including VLANs and L2
bridging, IPv4 and IPv6 unicast and multicast routing, DHCP L3 relay,
dual-homing of servers and upstream routers, QinQ
forwarding/termination, MPLS pseudowires, and so on. In addition,
Trellis can make the entire fabric appear as a single (virtual)
router to upstream routers, which communicate with Trellis using
standard BGP.</li>
</ul>
<p>Stratum (running on each switch) and ONOS (running off-switch and
managing a network of switches) communicate using the following
interfaces:</p>
<ul class="simple">
<li><strong>P4:</strong> Defines the forwarding behavior for programmable switching
chips as well as model fixed-function ASIC pipelines. A P4 program
defines a contract that is implemented by the data plane and
programmable by the control plane.</li>
<li><strong>P4Runtime:</strong> An SDN-ready interface for controlling forwarding
behavior at runtime. It is the key for populating forwarding tables
and manipulating forwarding state, and it does so in a P4 program and
hardware agnostic way.</li>
<li><strong>OpenConfig Models:</strong> Define a base for device configuration and
management. These models can be programmatically extended for
platform-specific functionality, but the goal is to minimize model
deviations so as to enable a vendor-agnostic management plane.</li>
<li><strong>gNMI</strong> (gRPC Network Management Interface): Improves on the
existing configuration interfaces by using a binary representation on
the wire and enabling bi-directional streaming. Paired with the
OpenConfig models, gNMI is SDN-ready.</li>
<li><strong>gNOI</strong> (gRPC Network Operations Interfaces): A collection of
microservices that enable switch specific operations, like
certificate management, device testing, software upgrade, and
networking troubleshooting. gNOI provides a semantically rich API
that replaces existing CLI-based approaches.</li>
</ul>
<p>Trellis, as an SDN control application running on top of ONOS, controls
packet forwarding across the switching fabric internal to a CORD POD
(i.e., within a single site). But Trellis can also be extended across
multiple sites deeper into the network using multiple stages of spines,
as shown in <a class="reference internal" href="#fig-trellis"><span class="std std-ref">Figure 6.3</span></a>. This means Trellis has the
potential to play a role in implementing the backhaul and midhaul
network for the RAN, or alternatively, extending the RAN into customer
premises (denoted “On Site” in the figure).</p>
<div class="figure align-center" id="id3">
<span id="fig-trellis"></span><a class="reference internal image-reference" href="_images/Slide31.png"><img alt="_images/Slide31.png" src="_images/Slide31.png" style="width: 600px;" /></a>
<p class="caption"><span class="caption-text">Figure 6.3: Trellis control application managing a (possibly
distributed) leaf-spine fabric.</span></p>
</div>
</div>
</div>
</div>
</div>
<footer>
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
<a href="cloud.html" class="btn btn-neutral float-right" title="Chapter 7: Cloudification of Access" accesskey="n" rel="next">Next <span class="fa fa-arrow-circle-right"></span></a>
<a href="disaggregate.html" class="btn btn-neutral float-left" title="Chapter 5: Advanced Capabilities" accesskey="p" rel="prev"><span class="fa fa-arrow-circle-left"></span> Previous</a>
</div>
<hr/>
<div role="contentinfo">
<p>
© Copyright 2019
</p>
</div>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/rtfd/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
</footer>
</div>
</div>
</section>
</div>
<script type="text/javascript">
jQuery(function () {
SphinxRtdTheme.Navigation.enable(true);
});
</script>
</body>
</html>