Background

Each time a new PNF is connected to the network, or reseted to factory settings, a PNF registration process is expected to happen.
Within this process, a VES pnfRegistration event is sent from a PNF instance to the ONAP/DCAE/VES collector.
In order to support Nomadic PNF use-case of a broader BBS use-case, an initial registration of a PNF needs to be distinguished from a re-registration.

Initial registration happens, when a PNF instance registers with ONAP for the first time (it was not used as a resource in any active service instance before).
Generally re-registration happens, when a PNF, that has been used previously in an active service instance, to deliver a service is re-connected or reset, and attempts to register again with ONAP with a pnfRegistration VES event.

Goal

The goal of this page is to summarize and prioritize the criteria, when a registration attempt is considered an initial registration and when - a Re-Registration.
All registration cases, which do not match with re-registration criteria will be considered "initial registrations".

Service/Resource instance state machine

SO project defined the State Machines, related to the service and resource (PNF/VNF) instances life-cycle.
The state machines are defined here. For PNFs, the state machine (simplified is stated as follows):

Register (when a PNF instance is created) → Registered (after initial pnfRegistration) → Assign → Assigned → ConfigAssign → ConfigAssigned → Configure → Configured → Active

Note:

At this moment (ONAP/Casablanca release), the orchestration states are not managed by the PNF PnP building block (state machine was not defined before).
Setting proper states within the PNF PnP BB according to this State Machine will probably be added at the beginning of ONAP/El Alto release.

Re-Registration criteria

The following criteria need to be applied (in the order given here), when evaluation, if a registration attempt is a Re-Registration:

  1. If a registration attempt is executed for a PNF Instance, which has an existing entry in the ONAP/AAI, and when that PNF instance is associated with an active (orchestration-status==active) service instance
    → Re-Registration
  2. If a registration attempt is executed for a PNF Instance, which has an existing entry in the ONAP/AAI, and when that PNF instance`s orchestration-status field is set to "Registered"
    → Re-Registration (possible starting from ONAP/El Alto release, when a PNF mgmt state machine is implemented)
  • No labels

12 Comments

  1. Tim Carey

    Damian,

    I think we need to know that

    1) the PNF entry exists and

    2) the PNF entry is active  (step 5 of the AAI inventory - requires an active PNF entry) I was thinking of the scenarios for this and I think we need to just need to know it exists. Sometimes the PNF entry won't be ready but can be relocated, right?


    I don't believe there needs to be an active service for re-registration 


    Then in the BBS case the attachment point would need to change - which would be the physical relocation scenario.


    1. Xin Miao

      Damian Nowak Tim Carey

      Yes. All we want to find out here is that there need to be an attribute in PNF entry in A&AI that can be used to verify different when the entry is found during PNF entry look-up upon receiving a PNF Registration event. 

      The question here is - is this PNF attribute set (by some use case specific to the generic mapping logic) at PNF registration time initially? And then this PNF attribute is compared later on with a string built based on the use case specific field (in case of Nomadic ONT is the OLT related fields + PON UNI ?)

      Only indication of activity in either service instance or PNF entry level may not be enough, since service/PNF activity indication cannot help distinguish the cases between PNF reset/reboot and relocation. 

      1. David Perez Caparros

        What about something like this?

        - PNF initial registration if (there is not PNF entry with that correlation ID in AAI) || (there is an entry in AAI with that PNF correlation ID and mandatory fields like oam IPv4, oam IPv6... are empty)
        - PNF re-registration if (there is an entry in AAI with that PNF correlation ID and mandatory fields like oam IPv4, oam IPv6... are not empty) <-- does this imply PNF active?
        - (in BBS or PRH uS?) PNF relocation if (PNF re-registration) && (PNF attachment point name in VES message differs from the one in AAI)

        PNF attachment point name can be stored in AAI as a string type attribute of the PNF resource model, e.g. PNF.attachmentPoint=olt1234/0/0, or as a logical interface in the list of p-interfaces of that PNF resource (as suggested by the modeling team), e.g. PNF.p-interface.l-interface.name=olt1234/0/0



        1. David Perez Caparros

          I see that only pnfRegistration FieldsVersion is mandatory in the VES message, not oam IPv4/6 addresses

        2. Tim Carey

          David,

          See my previous answer about active PNFs - actually I think they already know when a PNF is active already otherwise they couldn't issue the PNF ready event.

          Also see my comment on the p/l interface - are we sure the use of thel-interface isn't the sub-interface but a related attachment point?

          1. Keong Lim

            Tim Carey FYI , in AAI, the two names referred to above should be:

            • "p-interface" meaning "physical-interface"
            • "l-interface" meaning "logical-interface"

            There is currently no such "i-interface".

            The "logical-interface" can be a sub-object of:

            • vserver
            • l-interface
            • p-interface
            • lag-interface
            • generic-vnf
            • newvce


            Keong


            1. Tim Carey

              Sorry - old eyes it was an letter "L" not "I" my mistake.

        3. Damian Nowak

          PNF initial registration requires the empty PNF instance to exist in AAI. It is a part of an internal authentication mechanism (pnfRegistrations executed only for expected PNFs).
          PRH shall use only fields generic to all PNFs. Domain specific characteristics shall not really be used there (fields outside of PNF instance model in AAI), otherwise, PRH would be specific to use-cases coded/pre-configured in it - which we shall avoid, and keep it generic for all PNFs, including those, that will join in the future.

          Still, the BBS uS is able to apply this use-case specific processing (and in the future - Policy).

      2. Tim Carey

        Xin,


        We originally had a new field called "attachment point" that we were going to add to the PNF in AAI. It would be an opaque field that a simple comparison would indicate that a change in the attachment point.


        When David took that to the modelling team suggested we look at the PNF p-interface's, i-interface to store the information in the attachment point. 

        There is problems with this approach if I read the model correctly though, as the p-interface for the ONT PNF would be reflective of the ONT's NNI and the i-interface isn't an attachment point but the sub-interface of the ONT NNI's physical interface.   Now we would indeed use this to create an ONT NNI if we needed to. But to represent the PON UNI - I can't see that. If we formally modelled it, the PON UNI CP would be part of the relationship-list of the i or p interface of the ONT NNI. But as we said - we can't guarantee the PON UNI is instantiated yet so - we are back to the original idea of the attachment point field.

        1. David Perez Caparros

          I agree with you, Tim. Using an l-interface (logical interface) in the ONT PNF is not the ideal solution for modeling the OLT attachment point. AFAIK, A PNF can have multiple p-interfaces (physical), each p-interface can have multiple l-interfaces, e.g. vNIC. We could use a l-interface or perhaps a p-interface with, for instance, interface-role set to 'attachmentPoint' and name set to, e.g. olt1234/0/0. This way we avoid adding the opaque string attribute to the PNF model, which in reality does not belong to the PNF resource model itself either. As you said, it is a relationship.

    2. David Perez Caparros

      Tim,

      Sometimes the PNF entry won't be ready but can be relocated, right?

      I am not sure if we considered that case so far, PNF not ready > service not ready + relocation. When does a PNF become ready in our use case? 

      At the moment, we always assume that the HSIA service is up and running before the PNF is relocated.


      1. Damian Nowak

        So far the understanding of PNF "Ready" was, that this physical box is ready to be configured.
        In other words, we have in ONAP an OAM IP address to this box, which we can use to send configuration commands to (with NetConf, Ansible,...).

        Now, in this context, PNF could be Ready, and get re-located N times, and after each relocation, the data will be updated, and the final state will be "Ready".
        In ONAP/El Alto there is a proposal of established state machine, which defines here 2 states: "Register" (PNF created, but pnfRegistration not received yet), and "Registered" (after pnfRegistration recieved). And after that we have a bunch of states, which follow after we pass some conditions. Exactly this is the state transition "diagram":
        Register (when a PNF instance is created) → Registered (after initial pnfRegistration) → Assign → Assigned → ConfigAssign → ConfigAssigned → Configure → Configured → Active