Meeting Notes – Technology Profiles

Work areas – existing architecture:

Figure 1 Tech. Profile Work Areas for Discussion

ONOS Layer Discussion Points :

1)                         Add support for Flow Table ID Ref. to Tech. Profile ID

2)    Add Support For Meters for Upstream and Downstream Flows; Up to 2 Meter Bands Downstream, Up  to 3 Meter Bands Upstream

SADIS DB will cache Subscriber Service Records derived from an external management system URI or Database – it will contain a Technology Profile ID, Meter definition for Upstream and Downstream Flows, UNI match rules and actions to add a Subscriber identifying set of VLAN data.

Discussed how Tech. Profiles will be accessed in Key/Value Store e.g. etcd, Consul – decided on Technology Profile ID/Technology e.g. 255/XPON -> Blob of JSON data. Use existing CLI/Rest interfaces for accessing etcd DB. Consul could also be used – maybe issues with test scripts for Consul moving forward. Deprecate use of Consul after 2.0 Release?? Shawn would like all test scripts to be shared with Northforge.

Discussed use of Tech. Profiles for g.fast and if we currently see any impact on the Flow Table ID scalability given that the g.fast Profiles (See BBF TR-371) currently deployed can include Rate information e.g.

Line Configuration Profiles include:

        Service Related Profiles include:

• Downstream Data Rate Profile
• Upstream Data Rate Profile
• Low Power Date Rate Profile

AT&T currently use ~15 Spectrum Profile and ~10 Line Profiles which does not seem overly burdensome. However AT&T has not widely deployed at this point – maybe other Service Providers can provide input.

Perhaps we can use the Meter Bands to define some of the Profile data rate config e.g. Net Data Rate and Expected Throughput Minimum could be PIR and CIR? TBD.

VOLTHA Mgmt Layer Discussion Points :

3) Add support for Tech. Profile CRUD: CLI/Rest

1.                   Decided to initially support a Policy of only Create/Delete of Tech. Profiles initially;  though conceptually it was discussed having KV store issue a notification to all users of a Tech. Profile upon change so that all users can evaluate and respond. Use existing etcd tools for creating Tech Profiles.

4) Update OF-Agent to support Flow Table ID for Tech. Profile reference and Meter and Meter Band support (Flow/Meter Stats/counters also need adding).

1.       Need to support Error Checking for consistency – if Meter Ref then need Meter to exist first before reference. If Flow Table ID does not exist in KV Store generate an error – initial approach to simplify implementation. Still an argument for supporting doing such a check in the adapter since the VOLTHA core does not know what the technology key to use for a DB lookup. Could just do OF agent checks which do not need knowledge available in the adapter i.e. Meter Band Reference requires Meter Band definition first. Any Forward References need error checks (OF Error messages). Longer term issue – more complex path for validation of OF Messages – not initially supported.

VOLTHA Core Layer Discussion Points :

5) Add support for Tech. Profile Database Store/HA – used etcd – store as JSON ‘Blob’ of data

1.                   This would already be supported by KV Store – etcd clusterized HA already exists..

6) Add support for Tech. Profile Access based on Flow TableID/Technology Keys.

7) Flow Decomposer support for

a) Flow Table ID for Tech. Profile reference

b) Meter and Meter Band support

Use Existing architecture of Flow decomposer passing down to both OLT Adapter and ONU Adapter. OLT creates an Instance of the Tech. Profile incorporating all resources assigned for the Service Instance – TC Layer Attributes Alloc-ID, GEM Port-id, ONU-id. OLT Adapter managers the Instances creating an Instance Record in the etcd KV Store. The OLT Adapter will use the openFlow Flow-ID to identify the instance and will notify the ONU of its’ availability. The ONU will use the OF messages and the referenced Service Instance (Flow-id) to generate the OMCI messages to configure the ONU.

The OLT Adapter should have an Instance Manager which keeps track of the instances created per ONU and per ONU UNI – the creation of future instances is controlled by the two instance controls within the Tech. Profile (ONU and UNI) and the known history of the instance creation of a Tech Profile on a given ONU. 

Need to document how Flow Decomposer works.

8)                         Device and Adapter Agent support for updated OF message capabilities and Tech Profile

    Access. Device and Adapter Agent need to Pass all FlowTable  ID and  Meter data down to Adapters.

       9) Adapter Access to Tech. Profile based on Flow Table ID derived from OpenFlow Programming Messages – Derive Technology Key based on the Adapter Type. Key value lookup Table-ID/Technology Type to etcd.

Adapter Layer Discussion Points :

10) Adapter converts Tech. Profile plus OpenFlow Message data to create a Subscriber Service Instance.- etcd entry – need schemas defined.

11) OLT Adapter uses a Resource Manager to allocate available Alloc-ID/GEM Port-ID(s) to Subscriber Service Instance. Legacy OLTs may do this on OLT itself. For now OLT Adapter allocates TC layer parameters and stores in instance data. Do not need to share the TC Layer data between one PON Chassis and another i.e. between OLT Adapters. Type B Protection support may need ability to share TC Layer data in future ??. May need a common implementation of TC Layer Manager that could be shared between Adapter types. Not needed initially.

12) OLT Adapter initiates the ONU Service creation using the Tech. Profile and Service Instance data. – Note this is initiated by the ONU receiving the Flow Decomposer Flow Data and being notified from etcd. of the availability of the Tech Profile Instance Data – indexed by OF Flow-ID.  ONU needs both OF data from Flow Decomposer and the Instance Data before ONU configuration can occur.  Assumption is that the Flow ID uniquely identified the Instance within etcd.

13) ONU Adapter generates OMCI ME messages to create the Service. 

14) Support for Bottom-Up ONU Discovery/Authentication – Edgecore OLT needs to support the OpenFlow bottom up discovery scheme.

Logical port on the OLT Device ID represents an ONU/UNI. Need to support multiple UNI ports on an ONU. Need to support second Management channel for FCAPS support, need to manage ONU devices via this channel.