Class Diagram

Based on ONF Core IM (https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-content/uploads/2018/01/TR-512_v1.3.1_OnfCoreIm-info.zip).

ONAP Wan Connection IM is designed as below class diagram:

  • Wan Connection: The Wan Connection is Resource Composite.
  • Forwarding Construct: The Forwarding Construct (FC) class models enabled constrained potential for forwarding between interfaces at a particular specific layerProtocol. 
  • FC Port: Fowarding Construct Port. The association of the FC to interfaces is made via FC Ports. The FC Port class models the access to the FC function.  
  • Forwarding Domain: The Forwarding Domain (FD) class models the topological component that represents a forwarding capability that provides the opportunity to enable forwarding (of specific transport characteristic information at one or more protocol layers) between points.
  • FC Route: Each instance of an FC Route class models an individual route of an FC. The route of an FC object is represented by a list of FCs at a lower level with the implicit understanding that unmodeled link connections are interleaved between the lower level FCs.
  • Link: The Link class models effective adjacency between two or more ForwardingDomains (FD). 
  • LinkPort: The association of the Link to LTPs is made via LinkPort. The LinkPort class models the access to the Link function. 
  • LTP: The Logical Termination Point (LTP) class encapsulates the termination and adaptation functions of one or more transport layers represented by instances of LayerProtocol.


ONF CIM reference:

Class NameSDO Concept
Forwarding Construct

TR-512.2_OnfCoreIm-ForwardingAndTermination.pdf 3.2.3 ForwardingConstruct (FC) 

FC PortTR-512.2_OnfCoreIm-ForwardingAndTermination.pdf 3.2.2  FdPort 
Forwarding DomainTR-512.2_OnfCoreIm-ForwardingAndTermination.pdf 3.2.1  ForwardingDomain (FD) 
FC Route

TR-512.5_OnfCoreIm-Resilience.pdf 3.2.5  FcRoute 

Link

TR-512.2_OnfCoreIm-ForwardingAndTermination.pdf 3.2.5  Link 

LinkPortTR-512.2_OnfCoreIm-ForwardingAndTermination.pdf 3.2.6  LinkPort 
LTP

TR-512.2_OnfCoreIm-ForwardingAndTermination.pdf 3.1.1  LogicalTerminationPoint (LTP) 


The wan connection application for general scenario is shown as below diagram:

Notice: 

XC: Cross-Connect (TMF513_v3.1_070314.pdf 4.1.17  Cross-Connect), A Cross-Connect (XC) object shall represent a FC within a Network Element (NE). 

LC: Link Connection (T-REC-G[1].805-200003-I!!DOC-E.doc 5.2.2.1 Link connection), A link connection is capable of transferring information transparently across a link. It is delimited by ports and represents the fixed relation between the ends of the link. A link connection represents a pair of adaptation functions and a trail in the server layer network. LC is FC (TR-512.TM_OnfCoreIm-TerminologyMapping.pdf page 7)


There is a special resource class not shown in the class diagram above, that is specification. The classes of w an shown above are abstract, we could use them to describe any wan scenario with specify specification which has the specify parameters for the scenario. For example, we could use overlay vpn specification an FC to describe overlay vpn. All specify specification classes are derived from specification base class which is shown as below diagram: 

The specify specification class will be consumed by specify Direct Graph in SDN-C. As we could import specification class in SDC and import DG in SDN-C dynamically, new wan scenario could be taught to ONAP after version release.

Use Case Example

Take the ONAP R1 VoLTE use case as an example. Volte wan contains overlay vpn and underlay vpn, both of them could be described as a FC. And the relationship between overlay vpn and underlay vpn could be described by FCRoute and LinkConnection.

The class diagram of ONAP R1 VoLTE use case shown as below:

Wan descriptor node type definition example: WAN_type_definition.yaml

Volte Wan configuration node type definition example: WAN_Volte_wan_configuration_definition.yaml

Volte Wan template example: VoLTE_WAN_template.yaml

Class Dtail


  • No labels

19 Comments

  1. Andrei Kojukhov

    Hi Huang,

    There is no pictures can be seen in this page.

    Andrei

    1. Zhuoyao Huang

      Problem solved, thank you!

  2. Thinh Nguyenphu

    is this page, Design-Time Data Model: WAN Service represents TOSCA DM of the above concept?

    1. Zhuoyao Huang

      yes

  3. Srinivasa Addepalli

    What does 'sna' stand for?  Is PE example of 'sna'?

    1. Zhuoyao Huang

      'sna' stands for site-network-access, which are network accesses associated with the sites, and their properties. 

              +------------------+             Site
        |                  |-----------------------------------
        |                  |****** (site-network-access#1) ******
        |  New York Office |
        |                  |****** (site-network-access#2) ******
        |                  |-----------------------------------
        +------------------+

      'site-network-access' is based on ietf-l2sm/l3sm: 

      https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-04

      https://datatracker.ietf.org/doc/rfc8299/?include_text=1

      1. Srinivasa Addepalli

        Thank you.

        I am curious on why those IETF draft/RFC terms not used as is here.  Many understand terms such as L2VPN service, L3VPN Service, UNI, NNI , route-target, route-distinguisher etc...  


        1. Zhuoyao Huang

          These terms are all in the scope of configuration class, and will be kept in the name-value form. ONF CIM based WAN IM is more abstract model, it works like a skeleton, IETF draft/RFC terms could fit into it like the muscle.

  4. Thinh Nguyenphu

    Per wiki page introduction, this (Wan IM) came from ONF. I have the following comments:

    1) Please provide the reference of the ONF model, spec name, version and perhaps public link of the spec.

    2) As part of common information model collaboration back in 2016-2017, ETSI NFV, ONF and others SDOs defined a Touch Point between different models. (See IFA024 v2.1.1, Information Modeling; Report on External Touchpoints related to NFV Information Model, http://www.etsi.org/deliver/etsi_gr/NFV-IFA/001_099/024/02.01.01_60/gr_NFV-IFA024v020101p.pdf).  If we (ONAP) believes the ONF Wan model is applicable, then there should be only identify the touchpoints. see the picture below (ref: IFA024, figure 5.1-1).

    3) We need to extremely careful of not creating TOSCA types that already defined by ONF or other communities, such as ONF.

    4) How is this proposed IM and DM fit into the rest of ONF DM model?


    1. Andrei Kojukhov

      And I would also take into account a study report (that is currently being approved) in WAN domain in ETSI GR NFV-IFA22.

      1. Zhuoyao Huang

        Hi Andrei,

             ETSI GR NFV-IFA22 presents multiple use cases about WAN, and I believe ONF CIM could cover all of them. According ETSI GR NFV-IFA22 

        6.4.5.3.2, new information elements are needed to specify the detail connectivity information on the WAN, and according NFV-IFA024, ONF CIM might be a good choice to fill the gap. So the proposal on this page is based on ONF CIM.

    2. Zhuoyao Huang

      1) Please provide the reference of the ONF model, spec name, version and perhaps public link of the spec.
      Zhuoyao:
      Reference?TR-512_v1.3.1_OnfCoreIm-info
      https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-content/uploads/2018/01/TR-512_v1.3.1_OnfCoreIm-info.zip


      2) As part of common information model collaboration back in 2016-2017, ETSI NFV, ONF and others SDOs defined a Touch Point between different models. (See IFA024 v2.1.1, Information Modeling; Report on External Touchpoints related to NFV Information Model, http://www.etsi.org/deliver/etsi_gr/NFV-IFA/001_099/024/02.01.01_60/gr_NFV-IFA024v020101p.pdf). If we (ONAP) believes the ONF Wan model is applicable, then there should be only identify the touchpoints. see the picture below (ref: IFA024, figure 5.1-1).
      Zhuoyao:
      ONF just begin to lauch the TOSCA type definition of TR-512, and there is no output yet. For ONAP R2+, touch point might have nothing to touch.
      Besides, if we want to extend the ONF Core Im, touch point might not work.


      3) We need to extremely careful of not creating TOSCA types that already defined by ONF or other communities, such as ONF.
      Zhuoyao:
      ONF just begin to lauch the TOSCA type definition of TR-512, for ONAP R2+, it might has no output yet. I think we could define the WAN TOSCA type first, if ONF finish this job in the future, we could align with them.
      Reference:
      https://wiki.opennetworking.org/display/OIMT/UML+-+TOSCA+Mapping+Sub-team
      https://wiki.opennetworking.org/pages/worddav/preview.action?fileName=oimt2018.ND.003.00_ToscaFeedback-20180311.pptx&pageId=266141701


      4) How is this proposed IM and DM fit into the rest of ONF DM model?
      Zhuoyao:
      FC and FC Route is the same concept of ONF. FC Point is the same as FC port, and I will change its name latter.
      Link Connection, XC, XC Point, Node are extention for TR-512.
      Besides, configuration class contains the name-vlaue properties which could be consumed by SDN-C


  5. Jessie S Jewitt

    A few questions:

    1. Why is this work being done in the services group? All the ONF classes listed above, including FC are in the resource domain.
    2. Why are you borrowing XC, and XC Point from the TMF? These concepts exist in the ONF model.
    3. Also, why are you giving them different names from the TMF spec from which you take them? XC=Cross Connect. We shouldn't start calling them "exchange connections". 

  6. Zhuoyao Huang

    Why is this work being done in the services group? All the ONF classes listed above, including FC are in the resource domain.
    Zhuoyao:
    FC could be consider as service component.


    Why are you borrowing XC, and XC Point from the TMF? These concepts exist in the ONF model.
    Zhuoyao?
    In TR-512.TM_OnfCoreIm-TerminologyMapping.pdf page 7, we could find out corss connection is not ONF original. We could find the XC abbreviations in TR-512.1_OnfCoreIm-Overview.pdf page 35, but there is no detail in TR-512.DD_OnfCoreIm-DataDictionary.pdf. So I reference the TMF513_v3.1_070314.pdf  for more information.


    Also, why are you giving them different names from the TMF spec from which you take them? XC=Cross Connect. We shouldn't start calling them "exchange connections".
    Zhuoyao:
    Thank you for the advise, already changed!

  7. David Milham

    Folks

    TM Forum Resource Models and ONF

    Just to clarify some potential confusion evident in this discussion thread. I have captured in attached Word documents our TM Forum understanding of the current position of ONF and TM Forum Resource Models relationships.

     

  8. Jessie S Jewitt

    An FC is not considered a service, nor a service component. It is a resource concept. The entire model you propose is at the resource layer. Also, a XC gets modeled as an FC and probably should not be borrowed from the TMF. 

    1. Zhuoyao Huang

      Hi Jessie

           Thank you for your suggestion! WAN IM proposal might join the resource thread in latter discussion, and XC has been removed from the class diagram in the latest version.

           We know that XC is FC according TR-512.TM_OnfCoreIm-TerminologyMapping.pdf page 7. The idea of borrowing XC from TMF is based on the XC configuration parameters are quite different from higher level FC, and XC configurations might even quite different from each other if they belong to different providers. So we tried to treat XC different from FC in SDN-C process and let SDC user know XC is specify for the FC inside NE. But as the modeling discussion on last Sunday afternoon pointed out, XC concept will confuse the terminology, so it is not a good idea to keep it.

  9. Jessie S Jewitt

    Your information model is not a "WAN Descriptor IM". I've never heard of a WAN descriptor. It is a generalized resource model that can be used to model forwarding networks in support of multiple service types. As we are starting to put the ONAP model into Papyrus, this will be defined in the "resource" sub-domain of the model. Regarding your mapping to the DM, here are a few observations:

    1. The resource DM has prefixes like "tosca.node" or "tosca.datatype". Shouldn't you also be using "tosca" instead of "onap" as a prefix? Or vice-versa, should the resource DM types start with "onap"?  Why are some of them prefixed with "org.openecomp"? Where is the naming convention for Tosca templates defined?
    2. You put all your generalized resource concepts in Tosca as being prefixed by "onap.node.wan", like "onap.node.wan.Resource.Fc".  Again, these concepts are not specific to "wan". The Tosca template tree should mirror the Info Model tree and thus will fall in the "resource" domain, and not something called "wan".

    1. Zhuoyao Huang

      Hi Jessie

           ETSI already defied information model for NFV network service (NfvInformationModelv231.docx B.2.3.2 NsModule ), but WAN connectivity is the gap of the NFV model (NFV-IFA022v000802-clean.doc 6.4.5.3.2 Identified gaps and/or extensions), so we use ONF CIM to describe WAN and fill the gap. 

           The "org.openecomp" prefixes comes from SDC project seed code ( such as extCp.yml). The seed code origin from OpenEcomp, and I think the node types defined by OpenEcomp all have the "org.openecomp" prefixes. ONAP R1 and R2 SDC code succeed the convention, and I think it is ONAP now so I change the prefixes to "onap" in the proposal. But I think we could discuss the prefixes with SDC team and make it more properly.

            The "wan" prefixes specify the node types which fill the NFV model gaps. But I think it is reasonable to have same prefixes as ONF defined tosca type if we align NFV model and ONF model.