summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorqihuiz <zhaoqihui@chinamobile.com>2018-06-25 11:25:11 +0800
committerGergely Csatari <gergely.csatari@nokia.com>2018-08-10 12:53:37 +0200
commit3821e7480016b380e02e74026fc1c15ed7435468 (patch)
treee7a8170738c31b80b10f605da5e572c554c42522 /docs
parentf9d2683905dcbbfdc7e32245ce2a47725da8839a (diff)
Merging deployment scenarios
Deployment scenarios defined in the OpenStack Edge Computing Groups Dublin workshop notes [1] and in the initial change set of OPNFV Edge Cloud requirements document [1]. As the definition of deployment scenarios should be maintained only in one place OpenStack Edge Computing Group agreed [3] to merge the Dublin deployment scenarios to the OPNFV Edge Cloud requirements document in a way that in case of small and middle edge clouds the Dublin definitions are valid while in case of large edge clouds the OPNFV Edge Cloud definition is calid. This change implements this decision on top of [2]. [1]: https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#Deployment_Scenarios [2]: https://gerrit.opnfv.org/gerrit/#/c/58959/ [3]: http://eavesdrop.openstack.org/meetings/weekly_edge_computing_group_call/2018/weekly_edge_computing_group_call.2018-07-10-14.03.html Change-Id: Id647cbf2cc6af1ea53412616d622e06b349b6279 Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
Diffstat (limited to 'docs')
-rw-r--r--docs/development/requirements/requirements.rst138
1 files changed, 37 insertions, 101 deletions
diff --git a/docs/development/requirements/requirements.rst b/docs/development/requirements/requirements.rst
index 9706dd7..325fedf 100644
--- a/docs/development/requirements/requirements.rst
+++ b/docs/development/requirements/requirements.rst
@@ -199,10 +199,6 @@ Related project about acceleration: https://wiki.openstack.org/wiki/Cyborg
Edge Sites Conditions/ Deployment Scenarios
===========================================
-..
- Editors note: Any comments to this section should be added to https://gerrit.opnfv.org/gerrit/#/c/58959
- and not to this other reviews.
-
Latency and distance to customer are taken as two main characters to separate
different sites. The following figure shows three different sites.
@@ -210,16 +206,11 @@ different sites. The following figure shows three different sites.
:alt: Edge Sites Structure
:align: center
-
Small Edge
==========
-
-- Distance to base station: around 10km, closest site to end users / base station
-
-- E2E delay(from UE to site): around 2ms
-
+- Distance to base station: around 10 km, closest site to end users / base station
+- E2E delay(from UE to site): around 2 ms
- Maximum bandwidth can provide: 50 GB/s
-
- Minimum hardware specs: 1 unit of
- 4 cores (two ARM or Xeon-D processors)
@@ -232,141 +223,86 @@ Small Edge
- 64 GB RAM
- 1 * 1 TB storage
-- Power for a site: < 10KW
-
+- Power for a site: < 10 kW
- Physical access of maintainer: Rare, maintenance staff may only show up in
this kind of site when machines initialize for the first time or a machine
is down
-
- Physical security: none (Optionally secure booting is needed)
-
- Expected frequency of updates to hardware: 3-4 year refresh cycle
-
- Expected frequency of updates to firmware: 6-12 months
-
- Expected frequency of updates to control systems (e.g. OpenStack or
- Kubernetes controllers): ~ 12 - 24 months, has to be possible from
- remote management
-
-- Physical size: Not all the sites will have 36 depth capability. Some sites
- might be limited to 12 depth.
-
+ Kubernetes controllers): ~ 12 - 24 months, has to be possible from remote
+ management
+- Physical size: Not all the sites will have 36 inch depth capability. Some sites
+ might be limited to 12 inch depth.
- Number of edge cloud instances: depends on demands (3000+)
-
- Services might be deployed here: MEC, or other services which have strict
requirements on latency. Services deployed in this kind of sites have huge
regional deference
-
- Remote network connection reliability: No 100% uptime and variable
connectivity expected.
-
-- Orchestration: no orchestration component. MANO deployed in core site
- provide remote orchestration
-
-- Degree of virtualization: it is possible that no virtualization
- technology would be used in small edge site if virtualization
- increases structure/network complexity, reduce service performance,
- or cost more resources. Bare-metal is common in small edge sites.
- Container would also be a future choice if virtualization was needed
-
-- Storage: mainly consider local storage. Distributed storage would be
- used depending on services’ needs and site conditions.
+- Orchestration: no orchestration component. MANO deployed in core site provide
+ remote orchestration
+- Degree of virtualization: it is possible that no virtualization technology would
+ be used in small edge site if virtualization increases structure/network complexity,
+ reduces service performance, or costs more resources. Bare-metal is common in small
+ edge sites. Container would also be a future choice if virtualization was needed
+- Storage: mainly local storage.
Medium Edge
===========
- Distance to base station: around 50 km
-
-- E2E delay (from UE to site): less than 2.5ms
-
+- E2E delay (from UE to site): less than 2.5 ms
- Maximum bandwidth can provide: 100 GB/s
-
-- Minimum hardware specs: 2 RU
-
-- Maximum hardware specs: 20 RU
-
+- Minimum hardware specs: 2 Rack Unit (RU)
+- Maximum hardware specs: 20 Rack Unit
- Power for a site: 10 - 20 10 kW
-
- Physical access of maintainer: Rare
-
-- Physical security: Medium, probably not in a secure data center,
- probably in a semi-physically secure environment; each device has some
- authentication (such as certificate) to verify it's a legitimate
- piece of hardware deployed by operator; network access is all
- through security enhanced methods (vpn, connected back to dmz);
- VPN itself is not considered secure, so other mechanism such
- as https should be employed as well)
-
+- Physical security: Medium, probably not in a secure data center, probably in
+ a semi-physically secure environment; each device has some authentication
+ (such as certificate) to verify it's a legitimate piece of hardware deployed
+ by operator; network access is all through security enhanced methods (vpn,
+ connected back to dmz); VPN itself is not considered secure, so other
+ mechanism such as https should be employed as well)
- Expected frequency of updates to hardware: 5-7 years
-
-- Expected frequency of updates to firmware: Never unless required to
- fix blocker/critical bug(s)
-
-- Expected frequency of updates to control systems (e.g. OpenStack or
- Kubernetes controllers): 12 - 24 months
-
+- Expected frequency of updates to firmware: Never unless required to fix blocker/critical bug(s)
+- Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): 12 - 24 months
- Physical size: TBD
-
- Number of edge cloud instances: 3000+
-
- Services might be deployed here: MEC, RAN, CPE, etc.
-
-- Remote network connection reliability: 24/7 (high uptime but connectivity
- is variable), 100% uptime expected
-
+- Remote network connection reliability: 24/7 (high uptime but connectivity is
+ variable), 100% uptime expected
- Orchestration: no orchestration component. MANO deployed in core site
provide remote orchestration.
-
- Degree of virtualization: depends on site conditions and service requirements.
VM, container may form hybrid virtualization layer. Bare-metal is possible in
middle sites
-
-- Storage: local storage and distributed storage, which depends on site
- conditions and services’ needs
-
+- Storage: local storage and distributed storage, which depends on site conditions
+ and services’ needs
Large Edge
==========
-- Distance to base station: 100*x km (0.8<x<3)
-
-- E2E delay: around 4ms
-
+- Distance to base station: 100 x km (0.8<x<3)
+- E2E delay: around 4 ms
- Maximum bandwidth can provide: 200 GB/s
-
- Minimum hardware specs: N/A
-
- Maximum hardware specs: 100+ servers
-
- Power for a site: 20 - 90 kW
-
-- Physical access of maintainer: professional maintainer will monitor the
- site
-
+- Physical access of maintainer: professional maintainer will monitor the site
- Physical security: High
-
- Expected frequency of updates to hardware: 36 month
-
-- Expected frequency of updates to firmware: Never unless required to fix
- blocker/critical bug(s)
-
-- Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes
- controllers): 12 - 24 months
-
+- Expected frequency of updates to firmware: Never unless required to fix blocker/critical bug(s)
+- Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): 12 - 24 months
- Physical size: same as a normal DC
-
- Number of edge cloud instances: 600+
-
- Services might be deployed here: CDN, SAE-GW, UPF, CPE and etc., which have
- large bandwidth requirements and relatively small latency requirements
-
+ large bandwidth requirements and relatively low latency requirements
- Remote network connection reliability: reliable and stable
-
- Orchestration: no orchestration component. MANO deployed in core site provide
remote orchestration
-
- Degree of virtualization: almost completely virtualized in the form of VMs
- (if take CDN into consideration, which may not be virtualized, the
- virtualization degree would decrease in sites with CDN deployment)
-
+ (if take CDN into consideration, which may not be virtualized, the virtualization
+ degree would decrease in sites with CDN deployment)
- Storage: distributed storage
==============