From 0d4093efcbb909373c49bd02f6d6bd31edc385c2 Mon Sep 17 00:00:00 2001 From: Georg Kunz Date: Wed, 25 May 2016 17:21:28 +0200 Subject: Splitting L3VPN use cases into separate files for conflict free editing Change-Id: I6df2b672c6a67e4c06536075101212cddce2cb63 Signed-off-by: Georg Kunz --- docs/requirements/use_cases.rst | 2 +- docs/requirements/use_cases/l3vpn.rst | 11 + docs/requirements/use_cases/l3vpn_any_to_any.rst | 143 +++++++++++ docs/requirements/use_cases/l3vpn_ecmp.rst | 57 +++++ .../requirements/use_cases/l3vpn_hub_and_spoke.rst | 84 ++++++ docs/requirements/use_cases/use_cases_l3vpn.rst | 281 --------------------- 6 files changed, 296 insertions(+), 282 deletions(-) create mode 100644 docs/requirements/use_cases/l3vpn.rst create mode 100644 docs/requirements/use_cases/l3vpn_any_to_any.rst create mode 100644 docs/requirements/use_cases/l3vpn_ecmp.rst create mode 100644 docs/requirements/use_cases/l3vpn_hub_and_spoke.rst delete mode 100644 docs/requirements/use_cases/use_cases_l3vpn.rst (limited to 'docs/requirements') diff --git a/docs/requirements/use_cases.rst b/docs/requirements/use_cases.rst index ea2810b..fd3a6f0 100644 --- a/docs/requirements/use_cases.rst +++ b/docs/requirements/use_cases.rst @@ -7,7 +7,7 @@ Use cases The following sections address networking use cases that have been identified to be relevant in the scope of NFV and NetReady. .. toctree:: - use_cases/use_cases_l3vpn.rst + use_cases/l3vpn.rst use_cases/shared_service_functions.rst use_cases/programmable_provisioning.rst use_cases/georedundancy.rst diff --git a/docs/requirements/use_cases/l3vpn.rst b/docs/requirements/use_cases/l3vpn.rst new file mode 100644 index 0000000..5eb1a8a --- /dev/null +++ b/docs/requirements/use_cases/l3vpn.rst @@ -0,0 +1,11 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Bin Hu + +L3VPN Use Cases +=============== + +.. toctree:: + l3vpn_any_to_any.rst + l3vpn_ecmp.rst + l3vpn_hub_and_spoke.rst diff --git a/docs/requirements/use_cases/l3vpn_any_to_any.rst b/docs/requirements/use_cases/l3vpn_any_to_any.rst new file mode 100644 index 0000000..4ad6a98 --- /dev/null +++ b/docs/requirements/use_cases/l3vpn_any_to_any.rst @@ -0,0 +1,143 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Bin Hu + +Service Providers' virtualized network infrastructure may consist of one or more +SDN Controllers from different vendors. Those SDN Controllers may be managed +within one cloud or multiple clouds. Jointly, those VIMs (e.g. OpenStack instances) +and SDN Controllers work together in an interoperable framework to create L3 services +in Service Providers' virtualized network infrastructure. + +Three use cases of creating L3VPN service by multiple SDN Controllers are described +as follows. + +Any-to-Any Base Case +-------------------- + +Description +~~~~~~~~~~~ + +There are 2 hosts (compute nodes). SDN Controller A and vRouter A are provided by +Vendor A, and run on host A. SDN Controller B and vRouter B are provided by +Vendor B, and run on host B. + +There are 2 tenants. Tenant 1 creates L3VPN Blue with 2 subnets: 10.1.1.0/24 and 10.3.7.0/24. +Tenant 2 creates L3VPN Red with 1 subnet, overlapping address space: 10.1.1.0/24. + +The network topology is shown in :numref:`l3vpn-any2any-figure`: + +.. figure:: images/l3vpn-any2any.png + :name: l3vpn-any2any-figure + :width: 100% + +In L3VPN Blue, VMs G1 (10.1.1.5) and G2 (10.3.7.9) are spawned on host A, and attached to 2 subnets +(10.1.1.0/24 and 10.3.7.0/24) and assigned IP addresses respectively. VMs G3 (10.1.1.6) and +G4 (10.3.7.10) are spawned on host B, and attached to 2 subnets (10.1.1.0/24 and 10.3.7.0/24) +and assigned IP addresses respectively. + +In L3VPN Red, VM G5 (10.1.1.5) is spawned on host A, and attached to subnet 10.1.1.0/24. VM G6 +(10.1.1.6) is spawned on host B, and attached to the same subnet 10.1.1.0/24. + +VRF Lets us do: + +1. Overlapping Addresses + +2. Segregation of Traffic + +Derrived Requirements +~~~~~~~~~~~~~~~~~~~~~ + - TBD + +Northbound API / Workflow ++++++++++++++++++++++++++ + +Exemplary workflow is described as follows: + +1. Create Network + +2. Create Network VRF Policy Resource ``Any-to-Any`` + + 2.1. This sets up that when this tenant is put on a HOST that: + + 2.1.1. There will be a RD assigned per VRF + + 2.1.2. There will be a RT used for the common any-to-any communication + +3. Create Subnet + +4. Create Port (subnet, network vrf policy resource). This causes controller to: + + 4.1. Create vrf in vRouter's FIB, or Update vrf if already exists + + 4.2. Install an entry for Guest's HOST-Route in FIBs of Vrouters serving this tenant Virtual Network + + 4.3. Announce Guest HOST-Route to WAN-GW via MP-BGP + + + +Data model objects +++++++++++++++++++ + - TBD + + +Orchestration ++++++++++++++ + - TBD + + +Dependencies on compute services +++++++++++++++++++++++++++++++++ + - TBD + + + +Potential implementation +~~~~~~~~~~~~~~~~~~~~~~~~ + +Support for creating and managing L3VPNs is available in OpenStack Neutron by +means of the BGPVPN project [BGPVPN]_. In order to create the L3VPN network +configuration described above using the API BGPVPN API, the following workflow +is needed: + +1. Create a Neutron network "blue" + + :code:`neutron net-create blue` + + +2. Create the first Neutron subnet of the network "blue" + + :code:`neutron subnet-create 10.1.1.0/24` + + +3. Create the second Neutron subnet of the network "blue" + + :code:`neutron subnet-create 10.3.7.0/24` + + +4. Create a L3VPN by means of the BGPVPN API + + :code:`neutron bgpvpn-create --route-targets 64512:1 --tenant-id --name blue` + + +5. Associate the L3VPN with the previously created network + + :code:`neutron bgpvpn-net-assoc-create blue --network ` + + This command associates the given Neutron network with the L3VPN. The semantic + of this operation is that all subnets bound to the network are getting + interconnected through the BGP VPN and hence VMs located in either subnet can + communicate with each other. + + +Gaps in the current solution +~~~~~~~~~~~~~~~~~~~~~~~~ + +TBD + + +Conclusion +~~~~~~~~~~ + +TBD + + diff --git a/docs/requirements/use_cases/l3vpn_ecmp.rst b/docs/requirements/use_cases/l3vpn_ecmp.rst new file mode 100644 index 0000000..c218179 --- /dev/null +++ b/docs/requirements/use_cases/l3vpn_ecmp.rst @@ -0,0 +1,57 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Bin Hu + +ECMP Load Splitting Case (Anycast) +---------------------------------- + +Description +~~~~~~~~~~~ + +There are 2 hosts (compute nodes). SDN Controller A and vRouter A are provided by +Vendor A, and run on host A. SDN Controller B and vRouter B are provided by +Vendor B, and run on host B. + +There is 1 tenant. Tenant 1 creates L3VPN Blue with subnet 10.1.1.0/24. + +The network topology is shown in :numref:`l3vpn-ecmp-figure`: + +.. figure:: images/l3vpn-ecmp.png + :name: l3vpn-ecmp-figure + :width: 100% + +In L3VPN Blue, VNF1.1 and VNF1.2 are spawned on host A, attached to subnet 10.1.1.0/24 +and assigned the same IP address 10.1.1.5. VNF1.3 is spawned on host B, attached to +subnet 10.1.1.0/24 and assigned the same IP addresses 10.1.1.5. VNF 2 and VNF 3 are spawned +on host A and B respectively, attached to subnet 10.1.1.0/24, and assigned different IP +addresses 10.1.1.6 and 10.1.1.3 respectively. + +Here, the Network VRF Policy Resource is ``ECMP/AnyCast``. Traffic to **Anycast 10.1.1.5** +can be load split from either WAN GW or another VM like G5. + + +Derrived Requirements +~~~~~~~~~~~~~~~~~~~~~ + - TBD + +Northbound API / Workflow ++++++++++++++++++++++++++ + - TBD + +Data model objects +++++++++++++++++++ + - TBD + +Orchestration ++++++++++++++ + - TBD + +Dependencies on compute services +++++++++++++++++++++++++++++++++ + - TBD + +Potential implementation +++++++++++++++++++++++++ + - TBD + + diff --git a/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst b/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst new file mode 100644 index 0000000..455c686 --- /dev/null +++ b/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst @@ -0,0 +1,84 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Bin Hu + +Hub and Spoke Case +------------------ + +Description +~~~~~~~~~~~ + +There are 2 hosts (compute nodes). SDN Controller A and vRouter A are provided by +Vendor A, and run on host A. SDN Controller B and vRouter B are provided by +Vendor B, and run on host B. + +There is 1 tenant. Tenant 1 creates L3VPN Blue with 2 subnets: 10.1.1.0/24 and 10.3.7.0/24. + +The network topology is shown in :numref:`l3vpn-hub-spoke-figure`: + +.. figure:: images/l3vpn-hub-spoke.png + :name: l3vpn-hub-spoke-figure + :width: 100% + +In L3VPN Blue, vFW(H) is acting the role of ``hub`` (a virtual firewall). +The other 3 VNFsVMs are ``spoke``. vFW(H) and VNF1(S) are spawned on host A, +and VNF2(S) and VNF3(S) are spawned on host B. vFW(H) (10.1.1.5) and VNF2(S) +(10.1.1.6) are attached to subnet 10.1.1.0/24. VNF1(S) (10.3.7.9) and VNF3(S) +(10.3.7.10) are attached to subnet 10.3.7.0/24. + +Exemplary vFW(H) Hub VRF is as follows: + +* RD1 10.1.1.5 IP_OVR1 Label1 +* RD1 0/0 IP_OVR1 Label1 +* Label 1 Local IF (10.1.1.5) +* RD3 10.3.7.9 IP_OVR1 Label2 +* RD2 10.1.1.6 IP_OVR2 Label3 +* RD4 10.3.7.10 IP_OVR2 Label3 + +Exemplary VNF1(S) Spoke VRF is as follows: + +* RD1 0/0 IP_OVR1 Label1 +* RD3 10.3.7.9 IP_OVR1 Label2 + +Exemplary workflow is described as follows: + +1. Create Network + +2. Create VRF Policy Resource + + 2.1. Hub and Spoke + +3. Create Subnet + +4. Create Port + + 4.1. Subnet + + 4.2. VRF Policy Resource, [H | S] + + +Derrived Requirements +~~~~~~~~~~~~~~~~~~~~~ + - TBD + +Northbound API / Workflow ++++++++++++++++++++++++++ + - TBD + +Data model objects +++++++++++++++++++ + - TBD + +Orchestration ++++++++++++++ + - TBD + +Dependencies on compute services +++++++++++++++++++++++++++++++++ + - TBD + +Potential implementation +++++++++++++++++++++++++ + - TBD + + diff --git a/docs/requirements/use_cases/use_cases_l3vpn.rst b/docs/requirements/use_cases/use_cases_l3vpn.rst deleted file mode 100644 index f39671c..0000000 --- a/docs/requirements/use_cases/use_cases_l3vpn.rst +++ /dev/null @@ -1,281 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) Bin Hu - -L3VPN Use Cases -=============== - -Service Providers' virtualized network infrastructure may consist of one or more -SDN Controllers from different vendors. Those SDN Controllers may be managed -within one cloud or multiple clouds. Jointly, those VIMs (e.g. OpenStack instances) -and SDN Controllers work together in an interoperable framework to create L3 services -in Service Providers' virtualized network infrastructure. - -Three use cases of creating L3VPN service by multiple SDN Controllers are described -as follows. - -Any-to-Any Base Case --------------------- - -Description -~~~~~~~~~~~ - -There are 2 hosts (compute nodes). SDN Controller A and vRouter A are provided by -Vendor A, and run on host A. SDN Controller B and vRouter B are provided by -Vendor B, and run on host B. - -There are 2 tenants. Tenant 1 creates L3VPN Blue with 2 subnets: 10.1.1.0/24 and 10.3.7.0/24. -Tenant 2 creates L3VPN Red with 1 subnet, overlapping address space: 10.1.1.0/24. - -The network topology is shown in :numref:`l3vpn-any2any-figure`: - -.. figure:: images/l3vpn-any2any.png - :name: l3vpn-any2any-figure - :width: 100% - -In L3VPN Blue, VMs G1 (10.1.1.5) and G2 (10.3.7.9) are spawned on host A, and attached to 2 subnets -(10.1.1.0/24 and 10.3.7.0/24) and assigned IP addresses respectively. VMs G3 (10.1.1.6) and -G4 (10.3.7.10) are spawned on host B, and attached to 2 subnets (10.1.1.0/24 and 10.3.7.0/24) -and assigned IP addresses respectively. - -In L3VPN Red, VM G5 (10.1.1.5) is spawned on host A, and attached to subnet 10.1.1.0/24. VM G6 -(10.1.1.6) is spawned on host B, and attached to the same subnet 10.1.1.0/24. - -VRF Lets us do: - -1. Overlapping Addresses - -2. Segregation of Traffic - -Derrived Requirements -~~~~~~~~~~~~~~~~~~~~~ - - TBD - -Northbound API / Workflow -+++++++++++++++++++++++++ - -Exemplary workflow is described as follows: - -1. Create Network - -2. Create Network VRF Policy Resource ``Any-to-Any`` - - 2.1. This sets up that when this tenant is put on a HOST that: - - 2.1.1. There will be a RD assigned per VRF - - 2.1.2. There will be a RT used for the common any-to-any communication - -3. Create Subnet - -4. Create Port (subnet, network vrf policy resource). This causes controller to: - - 4.1. Create vrf in vRouter's FIB, or Update vrf if already exists - - 4.2. Install an entry for Guest's HOST-Route in FIBs of Vrouters serving this tenant Virtual Network - - 4.3. Announce Guest HOST-Route to WAN-GW via MP-BGP - - - -Data model objects -++++++++++++++++++ - - TBD - - -Orchestration -+++++++++++++ - - TBD - - -Dependencies on compute services -++++++++++++++++++++++++++++++++ - - TBD - - - -Potential implementation -~~~~~~~~~~~~~~~~~~~~~~~~ - -Support for creating and managing L3VPNs is available in OpenStack Neutron by -means of the BGPVPN project [BGPVPN]_. In order to create the L3VPN network -configuration described above using the API BGPVPN API, the following workflow -is needed: - -1. Create a Neutron network "blue" - - :code:`neutron net-create blue` - - -2. Create the first Neutron subnet of the network "blue" - - :code:`neutron subnet-create 10.1.1.0/24` - - -3. Create the second Neutron subnet of the network "blue" - - :code:`neutron subnet-create 10.3.7.0/24` - - -4. Create a L3VPN by means of the BGPVPN API - - :code:`neutron bgpvpn-create --route-targets 64512:1 --tenant-id --name blue` - - -5. Associate the L3VPN with the previously created network - - :code:`neutron bgpvpn-net-assoc-create blue --network ` - - This command associates the given Neutron network with the L3VPN. The semantic - of this operation is that all subnets bound to the network are getting - interconnected through the BGP VPN and hence VMs located in either subnet can - communicate with each other. - - -Gaps in the current solution -~~~~~~~~~~~~~~~~~~~~~~~~ - -TBD - - -Conclusion -~~~~~~~~~~ - -TBD - - - - -ECMP Load Splitting Case (Anycast) ----------------------------------- - -Description -~~~~~~~~~~~ - -There are 2 hosts (compute nodes). SDN Controller A and vRouter A are provided by -Vendor A, and run on host A. SDN Controller B and vRouter B are provided by -Vendor B, and run on host B. - -There is 1 tenant. Tenant 1 creates L3VPN Blue with subnet 10.1.1.0/24. - -The network topology is shown in :numref:`l3vpn-ecmp-figure`: - -.. figure:: images/l3vpn-ecmp.png - :name: l3vpn-ecmp-figure - :width: 100% - -In L3VPN Blue, VNF1.1 and VNF1.2 are spawned on host A, attached to subnet 10.1.1.0/24 -and assigned the same IP address 10.1.1.5. VNF1.3 is spawned on host B, attached to -subnet 10.1.1.0/24 and assigned the same IP addresses 10.1.1.5. VNF 2 and VNF 3 are spawned -on host A and B respectively, attached to subnet 10.1.1.0/24, and assigned different IP -addresses 10.1.1.6 and 10.1.1.3 respectively. - -Here, the Network VRF Policy Resource is ``ECMP/AnyCast``. Traffic to **Anycast 10.1.1.5** -can be load split from either WAN GW or another VM like G5. - - -Derrived Requirements -~~~~~~~~~~~~~~~~~~~~~ - - TBD - -Northbound API / Workflow -+++++++++++++++++++++++++ - - TBD - -Data model objects -++++++++++++++++++ - - TBD - -Orchestration -+++++++++++++ - - TBD - -Dependencies on compute services -++++++++++++++++++++++++++++++++ - - TBD - -Potential implementation -++++++++++++++++++++++++ - - TBD - - -Hub and Spoke Case ------------------- - -Description -~~~~~~~~~~~ - -There are 2 hosts (compute nodes). SDN Controller A and vRouter A are provided by -Vendor A, and run on host A. SDN Controller B and vRouter B are provided by -Vendor B, and run on host B. - -There is 1 tenant. Tenant 1 creates L3VPN Blue with 2 subnets: 10.1.1.0/24 and 10.3.7.0/24. - -The network topology is shown in :numref:`l3vpn-hub-spoke-figure`: - -.. figure:: images/l3vpn-hub-spoke.png - :name: l3vpn-hub-spoke-figure - :width: 100% - -In L3VPN Blue, vFW(H) is acting the role of ``hub`` (a virtual firewall). -The other 3 VNFsVMs are ``spoke``. vFW(H) and VNF1(S) are spawned on host A, -and VNF2(S) and VNF3(S) are spawned on host B. vFW(H) (10.1.1.5) and VNF2(S) -(10.1.1.6) are attached to subnet 10.1.1.0/24. VNF1(S) (10.3.7.9) and VNF3(S) -(10.3.7.10) are attached to subnet 10.3.7.0/24. - -Exemplary vFW(H) Hub VRF is as follows: - -* RD1 10.1.1.5 IP_OVR1 Label1 -* RD1 0/0 IP_OVR1 Label1 -* Label 1 Local IF (10.1.1.5) -* RD3 10.3.7.9 IP_OVR1 Label2 -* RD2 10.1.1.6 IP_OVR2 Label3 -* RD4 10.3.7.10 IP_OVR2 Label3 - -Exemplary VNF1(S) Spoke VRF is as follows: - -* RD1 0/0 IP_OVR1 Label1 -* RD3 10.3.7.9 IP_OVR1 Label2 - -Exemplary workflow is described as follows: - -1. Create Network - -2. Create VRF Policy Resource - - 2.1. Hub and Spoke - -3. Create Subnet - -4. Create Port - - 4.1. Subnet - - 4.2. VRF Policy Resource, [H | S] - - -Derrived Requirements -~~~~~~~~~~~~~~~~~~~~~ - - TBD - -Northbound API / Workflow -+++++++++++++++++++++++++ - - TBD - -Data model objects -++++++++++++++++++ - - TBD - -Orchestration -+++++++++++++ - - TBD - -Dependencies on compute services -++++++++++++++++++++++++++++++++ - - TBD - -Potential implementation -++++++++++++++++++++++++ - - TBD - - -- cgit 1.2.3-korg