[onap-discuss] [E] [Onap-arc] Shared VNFs and Services
|
Ulas Kozat
Hi Gil,
Could you clarify why a non-shareable VNF/PNF can only support one slice instance (hence one slice type)? I would imagine that a VNF/PNF instance out of the box may be able to support both eMBB or URLLC slice types. At least for gNB whether virtualized or not, I expect this to be the norm.
Also, I would think it should be the access policies in the control plane not the NF implementation itself should render an NF shareable or not in practice. A network function is typically designed to serve multiple network flows (and hence almost always shareable from the traffic flows perspective). Thus it can be wrapped around by a proper network controller and be shared among services/users/access groups. Or it can be dedicated to a particular service/user/access group. Could you clarify if I misunderstood or misapplied your comment on “shareability” as an intrinsic feature of NF?
Thanks,
Ulas
--------------------------------------------------------------------------------------------------------------------------------------- Ulas C. Kozat, Ph.D. Futurewei Technologies, Inc. 2330 Central Expressway Santa Clara, CA 95050 Tel: +1-408-330-5143 Fax: +1-408-330-5088 E-mail: ukozat@... --------------------------------------------------------------------------------------------------------------------------------------- This e-mail and any attachments may contain confidential information from Futurewei, which are intended only for the person or entity whose email address appears above. Any use of the information attached or contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or any unapproved dissemination) by persons other than the intended recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender by phone or response email immediately and delete this original message.
From: onap-discuss@... [mailto:onap-discuss@...]
On Behalf Of Gil Bullard via Lists.Onap.Org
Sent: Thursday, June 6, 2019 10:01 AM To: fernando.oliveira@...; Srini <srinivasa.r.addepalli@...> Cc: onap-arc@...; onap-discuss@... Subject: Re: [onap-discuss] [E] [Onap-arc] Shared VNFs and Services
To add to what Vimal and Fred said, a VNF is “shareable” or not based on the way it is coded. If a VNF is onboarded as “shared” it is onboarded as such because it is coded with the ability to be “shared” through configuration. In the 5G case, as Fred’s example illustrates, it is the VNF configuration that drives how many slice instances an instance of that VNF will support at any given point in time. In the case of a non-shareable VNF that supports slicing, an instance of the VNF itself could support only a single slice instance; configuration of the VNF would only determine the characteristics of that single slice instance. (Presumably only core NFs, and not RAN NFs, would be “dedicated” to a single slice instance.
How a UE discovers a slice instance to use for a particular application purpose is out of the scope of the ONAP management of the NF that provides that slice instance, whether via a dedicated or shared NF instance. Gil
From:
fernando.oliveira@... <fernando.oliveira@...>
Hi Srini, My understanding is that the in 5G SBA, sharing access control is enforced by the “configuration” of the NFs themselves. An NF instance of a SBA “5G service” would register with the NRF declaring which slice(s) it has been configured to support. When another NF asks the NRF for an instance of a particular “5G service”, it also passes the slice(s) that need to be supported by that “service” instance. The NRF would select an appropriate NF instance of that “5G service” that has support for the requested slices(s). A non-shared NF instance would be configured with only the dedicated slice(s) while the shared NF instances would be configured with the dedicated slices as well as other slice(s). Regards, Fred
From: <onap-arc@...> on behalf of Srini <srinivasa.r.addepalli@...>
Hi,
As I understand from Tuesday architecture meeting that Networking slicing is one use case for Shared VNFs. In some cases, each slice would have dedicated VNF instances and in some cases, there are shared VNFs and shared PNFs. I understand from your presentation on how to represent the shared VNF in the model (during design time). What I did not see is on how the consumer would request for the VNF to be dedicated or use the shared one Or is it that if the VNF is onboarded as ‘shared’, is it always shared?
Reason for asking is this:
- In network slicing, there is a possibility that a given VNF is sharable only across set of network slices. For example, network slices belonging to an Enterprise can share the VNF, but not with network slices of other Enterprises.
How does designers/administrator provide the access control information on the sharing aspect?
Thanks
|
|
|
|
BULLARD, GIL <wb5674@...>
Ulas, The term “shareable” can mean many different things in many different contexts, and so I think what is needed here is a more precise definition of what “shareable” means in the context. Unfortunately I don’t have a precise definition in mind. I have examples and I have terminology such as “use experience”. Perhaps others can provide assistance in coming up with a formal definition.
But with respect to what I do have…
I have found that the examples of “VPN/VRF” and “Firewall” have been useful.
Regarding the first example, Wikipedia (the source of all knowledge) defines a VRF as follows:
In IP-based computer networks, virtual routing and forwarding (VRF) is a technology that allows multiple instances of a routing table to co-exist within the same router at the same time. One or more logical or physical interfaces may have a VRF and these VRFs do not share routes therefore the packets are only forwarded between interfaces on the same VRF. VRFs are the OSI layer 3 equivalent of a VLAN. Because the routing instances are independent, the same or overlapping IP addresses can be used without conflicting with each other. Network functionality is improved because network paths can be segmented without requiring multiple routers [1]
So VRF technology allows a given Router, call it vRouter_S, to be configured behave as if it were many router NF instances. In the terminology of my deck, I would say that vRouter_B has been coded with the ability to provide multiple “router experiences” through configuration. Now compare that to another Router, call it vRouter_D, that doesn’t support VRF technology. Of course from one perspective, vRouter_D is “shared” in the sense that it participates in the routing and forwarding of many packets and sessions from many different endpoints and networks. But I am using term “shareable” for the purposes of my deck to differentiate VNFs like vRouter_S from vRouter_D. I.e., I am using the term “shareable” to refer to a VNF that has been coded with the ability to provide multiple “experiences” of a particular type.
Regarding the second example, imagine a single NF, call it Shareable_FW VNF, that has been coded to allow multiple instances of independent “firewall rules table sets” to co-exist within that same NF at the same time. So for this VNF, both Coke and Pepsi could have their “firewall experience” provided through configuration of a single VNF instance without any compromise in security. I would refer to Shareable_FW VNF as being “shareable”. Contrast that to another NF, call it Dedicated_FW VNF that has not been coded in this way, but rather has been coded with only a single “firewall rules table set”. So for this VNF, the Service Provider would need to create separate instances of Dedicated_FW VNF for Coke and for Pepsi in order for them both to have their respective “firewall experiences”. This is, in fact, the example I used in my deck.
Hope this helps. Gil
From: Ulas Kozat <ukozat@...>
Sent: Thursday, June 06, 2019 1:49 PM To: onap-discuss@...; BULLARD, GIL <wb5674@...>; fernando.oliveira@...; Srini <srinivasa.r.addepalli@...> Cc: onap-arc@... Subject: RE: [onap-discuss] [E] [Onap-arc] Shared VNFs and Services
Hi Gil,
Could you clarify why a non-shareable VNF/PNF can only support one slice instance (hence one slice type)? I would imagine that a VNF/PNF instance out of the box may be able to support both eMBB or URLLC slice types. At least for gNB whether virtualized or not, I expect this to be the norm.
Also, I would think it should be the access policies in the control plane not the NF implementation itself should render an NF shareable or not in practice. A network function is typically designed to serve multiple network flows (and hence almost always shareable from the traffic flows perspective). Thus it can be wrapped around by a proper network controller and be shared among services/users/access groups. Or it can be dedicated to a particular service/user/access group. Could you clarify if I misunderstood or misapplied your comment on “shareability” as an intrinsic feature of NF?
Thanks,
Ulas
--------------------------------------------------------------------------------------------------------------------------------------- Ulas C. Kozat, Ph.D. Futurewei Technologies, Inc. 2330 Central Expressway Santa Clara, CA 95050 Tel: +1-408-330-5143 Fax: +1-408-330-5088 E-mail: ukozat@... --------------------------------------------------------------------------------------------------------------------------------------- This e-mail and any attachments may contain confidential information from Futurewei, which are intended only for the person or entity whose email address appears above. Any use of the information attached or contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or any unapproved dissemination) by persons other than the intended recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender by phone or response email immediately and delete this original message.
From: onap-discuss@... [mailto:onap-discuss@...]
On Behalf Of Gil Bullard via Lists.Onap.Org
To add to what Vimal and Fred said, a VNF is “shareable” or not based on the way it is coded. If a VNF is onboarded as “shared” it is onboarded as such because it is coded with the ability to be “shared” through configuration. In the 5G case, as Fred’s example illustrates, it is the VNF configuration that drives how many slice instances an instance of that VNF will support at any given point in time. In the case of a non-shareable VNF that supports slicing, an instance of the VNF itself could support only a single slice instance; configuration of the VNF would only determine the characteristics of that single slice instance. (Presumably only core NFs, and not RAN NFs, would be “dedicated” to a single slice instance.
How a UE discovers a slice instance to use for a particular application purpose is out of the scope of the ONAP management of the NF that provides that slice instance, whether via a dedicated or shared NF instance. Gil
From:
fernando.oliveira@... <fernando.oliveira@...>
Hi Srini, My understanding is that the in 5G SBA, sharing access control is enforced by the “configuration” of the NFs themselves. An NF instance of a SBA “5G service” would register with the NRF declaring which slice(s) it has been configured to support. When another NF asks the NRF for an instance of a particular “5G service”, it also passes the slice(s) that need to be supported by that “service” instance. The NRF would select an appropriate NF instance of that “5G service” that has support for the requested slices(s). A non-shared NF instance would be configured with only the dedicated slice(s) while the shared NF instances would be configured with the dedicated slices as well as other slice(s). Regards, Fred
From: <onap-arc@...> on behalf of Srini <srinivasa.r.addepalli@...>
Hi,
As I understand from Tuesday architecture meeting that Networking slicing is one use case for Shared VNFs. In some cases, each slice would have dedicated VNF instances and in some cases, there are shared VNFs and shared PNFs. I understand from your presentation on how to represent the shared VNF in the model (during design time). What I did not see is on how the consumer would request for the VNF to be dedicated or use the shared one Or is it that if the VNF is onboarded as ‘shared’, is it always shared?
Reason for asking is this:
How does designers/administrator provide the access control information on the sharing aspect?
Thanks
|
|
|
|
Ulas Kozat
Hi Gil,
I think I understand your examples and definition from “use experience” point of view. Though, I find it a bit constrained in terms of reusability of the same network function in different scenarios.
To have a further thought exercise, consider an OpenFlow switch with a single instance of a flow table (or cascade of tables). Consider another function external to the switch implementation (e.g., FlowVisor) that can partition the switch ports and/or flow space to provide distinct virtual OpenFlow switches to distinct network controllers. Each network controller thinks that it has its own dedicated OpenFlow switch.
From the “use experience” point of view, I can instantiate: (1) an OpenFlow network for Coke as a dedicated network with a group of OpenFlow switches and Coke controller. Or, (2) an OpenFlow network as a shared network between Coke and Pepsi with a group of shared OpenFlow switches, a shared FlowVisor function and one controller for Coke, another controller for Pepsi. To make this a bit more complicated, we can also configure the FlowVisor dynamically via a close-loop optimization in ONAP to change the share of the network among the controllers.
Clearly, OpenFlow switches as network functions are only usable by a single experience in (1) while they can be used by multiple experiences in (2). Thus, it was not the implementation but how I bundled that function in a network service made it “shareable”. If I have to follow your definitions, then I must expose OpenFlow switches and FlowVisor as a single shareable VNF which looks very coarse grain to me.
Similar examples can be given in 5G context as well.
Ulas
--------------------------------------------------------------------------------------------------------------------------------------- Ulas C. Kozat, Ph.D. Futurewei Technologies, Inc. 2330 Central Expressway Santa Clara, CA 95050 Tel: +1-408-330-5143 Fax: +1-408-330-5088 E-mail: ukozat@... --------------------------------------------------------------------------------------------------------------------------------------- This e-mail and any attachments may contain confidential information from Futurewei, which are intended only for the person or entity whose email address appears above. Any use of the information attached or contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or any unapproved dissemination) by persons other than the intended recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender by phone or response email immediately and delete this original message.
From: BULLARD, GIL [mailto:wb5674@...]
Sent: Thursday, June 6, 2019 2:34 PM To: Ulas Kozat <ukozat@...>; onap-discuss@...; fernando.oliveira@...; Srini <srinivasa.r.addepalli@...> Cc: onap-arc@... Subject: RE: [onap-discuss] [E] [Onap-arc] Shared VNFs and Services
Ulas, The term “shareable” can mean many different things in many different contexts, and so I think what is needed here is a more precise definition of what “shareable” means in the context. Unfortunately I don’t have a precise definition in mind. I have examples and I have terminology such as “use experience”. Perhaps others can provide assistance in coming up with a formal definition.
But with respect to what I do have…
I have found that the examples of “VPN/VRF” and “Firewall” have been useful.
Regarding the first example, Wikipedia (the source of all knowledge) defines a VRF as follows:
In IP-based computer networks, virtual routing and forwarding (VRF) is a technology that allows multiple instances of a routing table to co-exist within the same router at the same time. One or more logical or physical interfaces may have a VRF and these VRFs do not share routes therefore the packets are only forwarded between interfaces on the same VRF. VRFs are the OSI layer 3 equivalent of a VLAN. Because the routing instances are independent, the same or overlapping IP addresses can be used without conflicting with each other. Network functionality is improved because network paths can be segmented without requiring multiple routers [1]
So VRF technology allows a given Router, call it vRouter_S, to be configured behave as if it were many router NF instances. In the terminology of my deck, I would say that vRouter_B has been coded with the ability to provide multiple “router experiences” through configuration. Now compare that to another Router, call it vRouter_D, that doesn’t support VRF technology. Of course from one perspective, vRouter_D is “shared” in the sense that it participates in the routing and forwarding of many packets and sessions from many different endpoints and networks. But I am using term “shareable” for the purposes of my deck to differentiate VNFs like vRouter_S from vRouter_D. I.e., I am using the term “shareable” to refer to a VNF that has been coded with the ability to provide multiple “experiences” of a particular type.
Regarding the second example, imagine a single NF, call it Shareable_FW VNF, that has been coded to allow multiple instances of independent “firewall rules table sets” to co-exist within that same NF at the same time. So for this VNF, both Coke and Pepsi could have their “firewall experience” provided through configuration of a single VNF instance without any compromise in security. I would refer to Shareable_FW VNF as being “shareable”. Contrast that to another NF, call it Dedicated_FW VNF that has not been coded in this way, but rather has been coded with only a single “firewall rules table set”. So for this VNF, the Service Provider would need to create separate instances of Dedicated_FW VNF for Coke and for Pepsi in order for them both to have their respective “firewall experiences”. This is, in fact, the example I used in my deck.
Hope this helps. Gil
From: Ulas Kozat <ukozat@...>
Hi Gil,
Could you clarify why a non-shareable VNF/PNF can only support one slice instance (hence one slice type)? I would imagine that a VNF/PNF instance out of the box may be able to support both eMBB or URLLC slice types. At least for gNB whether virtualized or not, I expect this to be the norm.
Also, I would think it should be the access policies in the control plane not the NF implementation itself should render an NF shareable or not in practice. A network function is typically designed to serve multiple network flows (and hence almost always shareable from the traffic flows perspective). Thus it can be wrapped around by a proper network controller and be shared among services/users/access groups. Or it can be dedicated to a particular service/user/access group. Could you clarify if I misunderstood or misapplied your comment on “shareability” as an intrinsic feature of NF?
Thanks,
Ulas
--------------------------------------------------------------------------------------------------------------------------------------- Ulas C. Kozat, Ph.D. Futurewei Technologies, Inc. 2330 Central Expressway Santa Clara, CA 95050 Tel: +1-408-330-5143 Fax: +1-408-330-5088 E-mail: ukozat@... --------------------------------------------------------------------------------------------------------------------------------------- This e-mail and any attachments may contain confidential information from Futurewei, which are intended only for the person or entity whose email address appears above. Any use of the information attached or contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or any unapproved dissemination) by persons other than the intended recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender by phone or response email immediately and delete this original message.
From: onap-discuss@... [mailto:onap-discuss@...]
On Behalf Of Gil Bullard via Lists.Onap.Org
To add to what Vimal and Fred said, a VNF is “shareable” or not based on the way it is coded. If a VNF is onboarded as “shared” it is onboarded as such because it is coded with the ability to be “shared” through configuration. In the 5G case, as Fred’s example illustrates, it is the VNF configuration that drives how many slice instances an instance of that VNF will support at any given point in time. In the case of a non-shareable VNF that supports slicing, an instance of the VNF itself could support only a single slice instance; configuration of the VNF would only determine the characteristics of that single slice instance. (Presumably only core NFs, and not RAN NFs, would be “dedicated” to a single slice instance.
How a UE discovers a slice instance to use for a particular application purpose is out of the scope of the ONAP management of the NF that provides that slice instance, whether via a dedicated or shared NF instance. Gil
From:
fernando.oliveira@... <fernando.oliveira@...>
Hi Srini, My understanding is that the in 5G SBA, sharing access control is enforced by the “configuration” of the NFs themselves. An NF instance of a SBA “5G service” would register with the NRF declaring which slice(s) it has been configured to support. When another NF asks the NRF for an instance of a particular “5G service”, it also passes the slice(s) that need to be supported by that “service” instance. The NRF would select an appropriate NF instance of that “5G service” that has support for the requested slices(s). A non-shared NF instance would be configured with only the dedicated slice(s) while the shared NF instances would be configured with the dedicated slices as well as other slice(s). Regards, Fred
From: <onap-arc@...> on behalf of Srini <srinivasa.r.addepalli@...>
Hi,
As I understand from Tuesday architecture meeting that Networking slicing is one use case for Shared VNFs. In some cases, each slice would have dedicated VNF instances and in some cases, there are shared VNFs and shared PNFs. I understand from your presentation on how to represent the shared VNF in the model (during design time). What I did not see is on how the consumer would request for the VNF to be dedicated or use the shared one Or is it that if the VNF is onboarded as ‘shared’, is it always shared?
Reason for asking is this:
- In network slicing, there is a possibility that a given VNF is sharable only across set of network slices. For example, network slices belonging to an Enterprise can share the VNF, but not with network slices of other Enterprises.
How does designers/administrator provide the access control information on the sharing aspect?
Thanks
|
|
|
|
BULLARD, GIL <wb5674@...>
Ulas, I am not familiar with this use case or these network functions, and it seems to me to be a quite complex example. But if I am following correctly and you are willing to grant me some grace and understanding for any errors since I am doing this in a rush on a Friday afternoon so I can wrap up my Friday in time to play with my grandson, I will take a stab at it.
It sounds like partitioning the “router” by physical port is intended to provide something like a “layer 1 VPN” to Coke and Pepsi? I think in this example ONAP would view this as 3 managed “Resources” (NFs):
It sounds like the vFV would maintain a “map” of the ports of the corresponding pOF, allowing a manager (ONAP in this case) to define partitions of those ports (or not) that I will call “domains” (because I don’t know the proper term). I assume (I don’t know) that a single network controller instance could typically manage multiple OpenFlow switches, maintaining a separate routing table for each. It sounds like in this case the vFV acts a “broker” between pOF and vNC, making it look (to the vNC) that each “domain” is a separate OpenFlow switch.
With that understanding, let’s further assume for simplicity that ONAP wouldn’t need to configure a network controller to tell it the number of or which OpenFlow switches it will controller, but rather that the OpenFlow switches would be configured with the IP of the network controller and some appropriate authentication information such that the network controller would “discover” its OpenFlow switches. Let’s assume that same pattern applies here, with the vNC “discovering” (what it thinks to be) its OpenFlow switches (emulated by the vFV), and the vFV “discovering” its pOF NFs.
Let’s also assume that ONAP need not configure the vFV with the specific ports in the OpenFlow switch’s port map to assign to which “domain”, but rather ONAP only needs to tell the vFV how many ports to assign to that “domain”. The vFV will discover the number of ports its OpenFlow switch has, and will assign them appropriately to domains presented to it.
So in this case, with respect to ONAP management of the “Resources” described above…
ONAP doesn’t need to configure the vNC at all. I believe ONAP would *not* model this VNF as being “shareable” using my terminology.
ONAP does need to configure the pOF with the proper “network controller” IP address and authentication information, which in this case would be the IP of the vFV (and not the real network controller which is hidden). I believe ONAP would *not* model this PNF as being “shareable” using my terminology, because its configuration is monolithic (single instance).
ONAP does need to configure the vFV with the IP address of the vNC, its authentication information, and the set of pOF switch ports that it is responsible for managing, all of which is a monolithic configuration. ONAP also needs to configure the vFV as each “domain” is ordered by a particular “subscriber” (Coke and Pepsi), providing the number of ports for each “domain”. Because the vFV can support multiple (“N”) instances of “domain” I believe ONAP *would* model this VNF as being “shareable” using my terminology. Let’s use the term “virtual switch” to refer to the “experience” that each “domain” provides. In Option C of my proposal, we would refer to the “virtual switch” as being an “ANF”.
With respect to the “infrastructure” Services, I think there could be 2 or 1, depending on an analysis that would take more time than I can put into this.
Alternatively one could model the above as a single Service with all the NFs in its topology template, defining “scaling dimensions” to allow the capacity planner to scale the Service in 2 different dimensions: vFV, and pOF. But that is a bit more complex to describe so given the number of words I have already typed, I will go with the 2 Services as described above.
When Coke orders this Service, they would specify the locations of their offices. ONAP would decompose this into a single Resource, the Virtual_Switch ANF, and send to OOF for homing. OOF homing of ANFs involves finding the associated “providing VNF” instance, which in this case would be an instance of vFV in the context of Switch_Infra Service. OOF could use the locations provided to determine which vFV instances and associated pOF instances are within the proper geography for the locations provided. (Assume for simplicity they are all in the “range” of a single vFV.) OOF would then query the Controller for each vFV instance (in the context of Switch_Infra Service) to determine if that vFV instance has capacity to support a new “domain” with the corresponding number of ports. Based on the results OOF would select the optimum vFV instance.
ONAP SO would then orchestrate requesting the Controller to assign any network assignments needed to support a new “domain” (IP addresses, etc.), and then ask the Controller to create the corresponding ANF. The Controller would do so by configuring the target vFV with the appropriate information for the new “domain”, such as the number of ports, etc. A&AI would present the following objects:
Hope that helps. Given that I’m not going to take the time to re-read what I have written given other commitments, I hope that this was helpful and not confusion, and that I haven’t overlooked something basic.
Have a great weekend! Gil
From: onap-discuss@... <onap-discuss@...>
On Behalf Of Ulas Kozat
Sent: Thursday, June 06, 2019 8:13 PM To: BULLARD, GIL <wb5674@...>; onap-discuss@...; fernando.oliveira@...; Srini <srinivasa.r.addepalli@...> Cc: onap-arc@... Subject: Re: [onap-discuss] [E] [Onap-arc] Shared VNFs and Services
Hi Gil,
I think I understand your examples and definition from “use experience” point of view. Though, I find it a bit constrained in terms of reusability of the same network function in different scenarios.
To have a further thought exercise, consider an OpenFlow switch with a single instance of a flow table (or cascade of tables). Consider another function external to the switch implementation (e.g., FlowVisor) that can partition the switch ports and/or flow space to provide distinct virtual OpenFlow switches to distinct network controllers. Each network controller thinks that it has its own dedicated OpenFlow switch.
From the “use experience” point of view, I can instantiate:
Or,
Clearly, OpenFlow switches as network functions are only usable by a single experience in (1) while they can be used by multiple experiences in (2). Thus, it was not the implementation but how I bundled that function in a network service made it “shareable”. If I have to follow your definitions, then I must expose OpenFlow switches and FlowVisor as a single shareable VNF which looks very coarse grain to me.
Similar examples can be given in 5G context as well.
Ulas
--------------------------------------------------------------------------------------------------------------------------------------- Ulas C. Kozat, Ph.D. Futurewei Technologies, Inc. 2330 Central Expressway Santa Clara, CA 95050 Tel: +1-408-330-5143 Fax: +1-408-330-5088 E-mail: ukozat@... --------------------------------------------------------------------------------------------------------------------------------------- This e-mail and any attachments may contain confidential information from Futurewei, which are intended only for the person or entity whose email address appears above. Any use of the information attached or contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or any unapproved dissemination) by persons other than the intended recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender by phone or response email immediately and delete this original message.
From: BULLARD, GIL [mailto:wb5674@...]
Ulas, The term “shareable” can mean many different things in many different contexts, and so I think what is needed here is a more precise definition of what “shareable” means in the context. Unfortunately I don’t have a precise definition in mind. I have examples and I have terminology such as “use experience”. Perhaps others can provide assistance in coming up with a formal definition.
But with respect to what I do have…
I have found that the examples of “VPN/VRF” and “Firewall” have been useful.
Regarding the first example, Wikipedia (the source of all knowledge) defines a VRF as follows:
In IP-based computer networks, virtual routing and forwarding (VRF) is a technology that allows multiple instances of a routing table to co-exist within the same router at the same time. One or more logical or physical interfaces may have a VRF and these VRFs do not share routes therefore the packets are only forwarded between interfaces on the same VRF. VRFs are the OSI layer 3 equivalent of a VLAN. Because the routing instances are independent, the same or overlapping IP addresses can be used without conflicting with each other. Network functionality is improved because network paths can be segmented without requiring multiple routers [1]
So VRF technology allows a given Router, call it vRouter_S, to be configured behave as if it were many router NF instances. In the terminology of my deck, I would say that vRouter_B has been coded with the ability to provide multiple “router experiences” through configuration. Now compare that to another Router, call it vRouter_D, that doesn’t support VRF technology. Of course from one perspective, vRouter_D is “shared” in the sense that it participates in the routing and forwarding of many packets and sessions from many different endpoints and networks. But I am using term “shareable” for the purposes of my deck to differentiate VNFs like vRouter_S from vRouter_D. I.e., I am using the term “shareable” to refer to a VNF that has been coded with the ability to provide multiple “experiences” of a particular type.
Regarding the second example, imagine a single NF, call it Shareable_FW VNF, that has been coded to allow multiple instances of independent “firewall rules table sets” to co-exist within that same NF at the same time. So for this VNF, both Coke and Pepsi could have their “firewall experience” provided through configuration of a single VNF instance without any compromise in security. I would refer to Shareable_FW VNF as being “shareable”. Contrast that to another NF, call it Dedicated_FW VNF that has not been coded in this way, but rather has been coded with only a single “firewall rules table set”. So for this VNF, the Service Provider would need to create separate instances of Dedicated_FW VNF for Coke and for Pepsi in order for them both to have their respective “firewall experiences”. This is, in fact, the example I used in my deck.
Hope this helps. Gil
From: Ulas Kozat <ukozat@...>
Hi Gil,
Could you clarify why a non-shareable VNF/PNF can only support one slice instance (hence one slice type)? I would imagine that a VNF/PNF instance out of the box may be able to support both eMBB or URLLC slice types. At least for gNB whether virtualized or not, I expect this to be the norm.
Also, I would think it should be the access policies in the control plane not the NF implementation itself should render an NF shareable or not in practice. A network function is typically designed to serve multiple network flows (and hence almost always shareable from the traffic flows perspective). Thus it can be wrapped around by a proper network controller and be shared among services/users/access groups. Or it can be dedicated to a particular service/user/access group. Could you clarify if I misunderstood or misapplied your comment on “shareability” as an intrinsic feature of NF?
Thanks,
Ulas
--------------------------------------------------------------------------------------------------------------------------------------- Ulas C. Kozat, Ph.D. Futurewei Technologies, Inc. 2330 Central Expressway Santa Clara, CA 95050 Tel: +1-408-330-5143 Fax: +1-408-330-5088 E-mail: ukozat@... --------------------------------------------------------------------------------------------------------------------------------------- This e-mail and any attachments may contain confidential information from Futurewei, which are intended only for the person or entity whose email address appears above. Any use of the information attached or contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or any unapproved dissemination) by persons other than the intended recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender by phone or response email immediately and delete this original message.
From: onap-discuss@... [mailto:onap-discuss@...]
On Behalf Of Gil Bullard via Lists.Onap.Org
To add to what Vimal and Fred said, a VNF is “shareable” or not based on the way it is coded. If a VNF is onboarded as “shared” it is onboarded as such because it is coded with the ability to be “shared” through configuration. In the 5G case, as Fred’s example illustrates, it is the VNF configuration that drives how many slice instances an instance of that VNF will support at any given point in time. In the case of a non-shareable VNF that supports slicing, an instance of the VNF itself could support only a single slice instance; configuration of the VNF would only determine the characteristics of that single slice instance. (Presumably only core NFs, and not RAN NFs, would be “dedicated” to a single slice instance.
How a UE discovers a slice instance to use for a particular application purpose is out of the scope of the ONAP management of the NF that provides that slice instance, whether via a dedicated or shared NF instance. Gil
From:
fernando.oliveira@... <fernando.oliveira@...>
Hi Srini, My understanding is that the in 5G SBA, sharing access control is enforced by the “configuration” of the NFs themselves. An NF instance of a SBA “5G service” would register with the NRF declaring which slice(s) it has been configured to support. When another NF asks the NRF for an instance of a particular “5G service”, it also passes the slice(s) that need to be supported by that “service” instance. The NRF would select an appropriate NF instance of that “5G service” that has support for the requested slices(s). A non-shared NF instance would be configured with only the dedicated slice(s) while the shared NF instances would be configured with the dedicated slices as well as other slice(s). Regards, Fred
From: <onap-arc@...> on behalf of Srini <srinivasa.r.addepalli@...>
Hi,
As I understand from Tuesday architecture meeting that Networking slicing is one use case for Shared VNFs. In some cases, each slice would have dedicated VNF instances and in some cases, there are shared VNFs and shared PNFs. I understand from your presentation on how to represent the shared VNF in the model (during design time). What I did not see is on how the consumer would request for the VNF to be dedicated or use the shared one Or is it that if the VNF is onboarded as ‘shared’, is it always shared?
Reason for asking is this:
How does designers/administrator provide the access control information on the sharing aspect?
Thanks
|
|
|