Model abstracter

Enable/Disable Model Abstracter with env-variable MODEL_ABSTRACTER_STATUS

The environment variable MODEL_ABSTRACTER_STATUS is used in two scenarios.

Docker compose file

We could use docker-compose command to deploy OB-BAA. And add MODEL_ABSTRACTER_STATUS variable in node of services.baa.environment as follows. It’s only a part of docker-compose.yml file to demonstrate the usage.

version: '3.5'
        driver: bridge
        name: baadist_default
        image: baa
        build: ./
        container_name: baa
        restart: always
            - "8080:8080"
            - "5005:5005"
            - "9292:9292"
            - "4335:4335"
            - "162:162/udp"
            #- EXTRA_JAVA_OPTS=-Xms128M -Xmx512M -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
            - BAA_USER=admin
            - BAA_USER_PASSWORD=password
            #Possible Values for PMA_SESSION_FACTORY_TYPE are REGULAR,TRANSPARENT, Default value is REGULAR
            - VOLTMF_NAME=vOLTMF
            # Enable Model Abstracter or Disable Model Abstracter, Default value is Disable
            - MODEL_ABSTRACTER_STATUS=Disable
            # Below tag shall be set as false if the BAA is going to be tested for Scalability/Performance

Helm charts file

The helm chart file is used in Kubenetes, and need to add the variable in the deployment.yml of the baa chart. This variable should be added in the node of env as follows. It’s also a part of the deployment.yml file.

    type: Recreate
  replicas: 1
      app: baa
        app: baa
        - name: baa-store
            claimName: baa-pvclaim
      hostname: baa
        - name: baa
          image: broadbandforum/baa:latest
          imagePullPolicy: Always
            - name: http
              containerPort: 8080
              protocol: TCP
            - name: debug
              containerPort: 5005
              protocol: TCP
            - name: ncnbissh
              containerPort: 9292
              protocol: TCP
            - name: callhometls
              containerPort: 4335
              protocol: TCP
            - name: snmp
              containerPort: 162
              protocol: UDP
          stdin: true
          tty: true
            - name: BAA_USER
              value: admin
            - name: BAA_USER_PASSWORD
              value: password
            - name: PMA_SESSION_FACTORY_TYPE
              value: REGULAR
            - name: VOLTMF_NAME
              value: vOLTMF
            # Enable Model Abstracter or Disable Model Abstracter, Default value is Disable
            - name: MODEL_ABSTRACTER_STATUS
              value: Disable

L2 service configuration

The following describes how to config L2 service using the new YANG model. Note: the steps related to environment preparation which contains the pOLT and onu simulator are omitted below.

  1. Add OLT and ONU using ‘vomci-end-to-end-config’.
  2. Add ani and v-ani interfaces.
  3. Create a link table between ani and v-ani.
  4. Prepare profiles, e.g., line profile, service profile, and so on.
  5. Create OLT node and TPs.
  6. Create ONT node and TPs and LINK.
  7. Create L2-V-UNI and L2-V-NNI TPs.
  8. Create a link-only 1:1 scenario, this step is optional if you decide to create an N:1 scenario.
  9. Create an N:1 VLAN forwarding profile.
  10. Create N:1 L2 vlan tp.
  11. Create a link in the N:1 scenario.

The XML samples mentioned above are as follows:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3">
    <edit-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
            <running />
            <network-manager xmlns="urn:bbf:yang:obbaa:network-manager">
                            <if:interfaces xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">
                                    <if:type xmlns:bbf-xponift="urn:bbf:yang:bbf-xpon-if-type">bbf-xponift:v-ani</if:type>
                                    <bbf-xponvani:v-ani xmlns:bbf-xponvani="urn:bbf:yang:bbf-xponvani">
                                    <if:type xmlns:bbf-xponift="urn:bbf:yang:bbf-xpon-if-type">bbf-xponift:ani</if:type>
                                    <bbf-xponani:ani xmlns:bbf-xponani="urn:bbf:yang:bbf-xponani">
OLT1 ani.OLT1.onu1 v-ani.OLT1.onu1

bandwidth-profile-1 102400 102400 204800

- create-line-profile
line-profile-1 v-nni1 bandwidth-profile-1 mapping-index-1 200

- create-vlan-translation-profile
vlan-trans-profile-1 100 1 0 200 0 vlan-trans-profile-2 200 1 0 300 0 vlan-trans-profile-3 300 1 0 100 0

- create-service-profile

service-profile-1 eth.1 vlan-trans-profile-1

- create-OLT-node-and-TPs
network-fan1 network-fan1 OLT1 network-fan1 p-OLT1 uni1 network-fan1 OLT1 pon-tp1 uni nni1 network-fan1 OLT1 eth-tp1 nni

- create-ONU-node-and-TPs-and-LINK
network-fan1 onu1 line-profile-1 service-profile-1 network-fan1 p-onu1 uni1 network-fan1 onu1 lan-port-tp1 uni nni1 network-fan1 onu1 wan-port-tp1 nni link.OLT1.onu1 OLT1 uni1 onu1 nni1 bidirectional

- create-1-1-l2-v-uni-and-nni-tp E
network-fan1 onu1 l2-v-uni1 network-fan1 onu1 v-nni1 bbf-tp-types:l2-v-uni vlan-trans-profile-2 OLT1 l2-v-nni1 network-fan1 OLT1 nni1 bbf-tp-types:l2-v-nni vlan-trans-profile-3

- optional-create-link-only-1-1
network-fan1 l2-v-uni1-l2-v-nni1 onu1 l2-v-uni1 OLT1 l2-v-nni1 bidirectional

From here, it's the N:1 scenario, and this profile is only used in N:1 scenario.
- create-N-1-vlan-forwarding-profile
vlan-fwd-profile1 fport1 OLT1 nni1

- create-N-1-l2-vlan-tp
network-fan1 OLT1 l2-vlan300 l2-vlan 300 vlan-fwd-profile1

- optional-create-link-only-N-1 
network-fan1 l2-v-uni2-l2-vlan300 onu1 l2-v-uni1 OLT1 l2-vlan300 bidirectional