[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@...>
Sent: Thursday, June 06, 2019 12:52 PM
To: Srini <srinivasa.r.addepalli@...>; BULLARD, GIL <wb5674@...>
Cc: onap-arc@...; onap-discuss@...
Subject: Re: [E] [Onap-arc] Shared VNFs and Services

 

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@...>
Date: Thursday, June 6, 2019 at 11:55 AM
To: "gil.bullard@..." <gil.bullard@...>
Cc: "onap-arc@..." <onap-arc@...>, "onap-discuss@..." <onap-discuss@...>
Subject: [E] [Onap-arc] Shared VNFs and Services

 

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
Srini

 

 


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
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@...>
Sent: Thursday, June 06, 2019 12:52 PM
To: Srini <srinivasa.r.addepalli@...>; BULLARD, GIL <wb5674@...>
Cc: onap-arc@...; onap-discuss@...
Subject: Re: [E] [Onap-arc] Shared VNFs and Services

 

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@...>
Date: Thursday, June 6, 2019 at 11:55 AM
To: "gil.bullard@..." <gil.bullard@...>
Cc: "onap-arc@..." <onap-arc@...>, "onap-discuss@..." <onap-discuss@...>
Subject: [E] [Onap-arc] Shared VNFs and Services

 

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
Srini

 

 


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@...>
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
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@...>
Sent: Thursday, June 06, 2019 12:52 PM
To: Srini <srinivasa.r.addepalli@...>; BULLARD, GIL <wb5674@...>
Cc: onap-arc@...; onap-discuss@...
Subject: Re: [E] [Onap-arc] Shared VNFs and Services

 

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@...>
Date: Thursday, June 6, 2019 at 11:55 AM
To: "gil.bullard@..." <gil.bullard@...>
Cc: "onap-arc@..." <onap-arc@...>, "onap-discuss@..." <onap-discuss@...>
Subject: [E] [Onap-arc] Shared VNFs and Services

 

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
Srini

 

 


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):

  • The OpenFlow switch (let’s call it pOF, because I assume it is a PNF): this is the NF that provides the user plane function (forwarding function)
  • The “network controller” (let’s call it vNC): this is an NF that provides control plane function (routing function)
  • The FlowVisor (let’s call it vFV): this is an NF that also provides control plane function, sitting between the two abovementioned 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.

  • NC_Infra Service – The topology template of this Service would be comprised only of a single vNC node template.  If a capacity planner wanted to add another instance of vNC they would go to VID and request an instance of this Service.
  • Switch_Infra Service – The topology template of this Service would be comprised of a single vFV node template and perhaps a variable number of pOF node templates.  If a capacity planner wanted to add another instance of vFV and associated pOFs they would go to VID and request an instance of this Service, indicating the number of pOFs to discover.  Scaling the Service itself would result in adding pOF instances.

 

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.

 

  • Virtual_Switch Service – The topology template of this Service would be comprised of a single instance of the “Virtual_Switch ANF” as a node template.  The ANF would have a “Provided By” relationship to the vFV VNF in the context of the Switch_Infra Service.

 

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:

  • “Customer” object representing the business unit that “owns” the infrastructure, associated with a…
  • “Subscription” object representing that business unit’s involvement with the “Switch_Infra” Service, associated with a collection of…
  • “Service Instance” objects, each representing an instance of “Switch_Infra”, each associated with …
  • A single “VNF Instance” for the vFV and a collection of PNF instances for the pOFs.   The vFV VNF instance would have an association with…
  • An “ANF instance” for the “VIrtualSwitch ANF”, which would have an association with…
  • A “service instance” object, representing Coke’s instance of the “Virtual_Switch Service”, which would have an association with…
  • A “Subscription” object, representing Coke’s involvement with the “Virtual_Switch Service, which would have an association with…
  • A “Customer” object for Coke.

 

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:

  1. an OpenFlow network for Coke as a dedicated network with a group of OpenFlow switches and Coke controller.

Or,

  1. 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@...>
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
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@...>
Sent: Thursday, June 06, 2019 12:52 PM
To: Srini <srinivasa.r.addepalli@...>; BULLARD, GIL <wb5674@...>
Cc: onap-arc@...; onap-discuss@...
Subject: Re: [E] [Onap-arc] Shared VNFs and Services

 

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@...>
Date: Thursday, June 6, 2019 at 11:55 AM
To: "gil.bullard@..." <gil.bullard@...>
Cc: "onap-arc@..." <onap-arc@...>, "onap-discuss@..." <onap-discuss@...>
Subject: [E] [Onap-arc] Shared VNFs and Services

 

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
Srini