Phase 1 Planning ODTN

Size: px

Start display at page:

Download "Phase 1 Planning ODTN"

Erika Kennedy
5 years ago
Views:

1 Phase 1 Planning ODTN 1

2 Phase 1 Planning Session Logistics (30 mins) Team Formation Tasks and Schedule Test Lab Locations Tools Technical Scope of Work (rest of day) Use Case / Test Scenario Software Development Testing and Environment Environment Set up Wrap up & Next Steps 2

3 Action Items due today Team member assignment Pick suitable meeting timeslot for each teams & start dates Define work item until the first team meeting e.g., sketch of time line Start initial team discussion if there s time left 3

4 Team Formation Initial team leads and members to be confirmed during kick-off meeting Team Responsibility Expected Members Assignee Project Management (Chair/Co-Chair) Progress management, prioritization, etc. Service Providers, 1x ONF, 1x Tier 1 vendor See project steering team Use Case Define Use Cases Define Test Scenarios Select APIs / Models Metrics for success? Service Providers Rob (Comcast), Toru (NTT), Karthik (NEC), Nokia, Telefonica? Software Development Design and Implementation All Marc (ONF), Yuta (NEC), Nokia, ZTE, NTT, Telefonica partners?, Coriant, Oplink?, Infinera? Infrastructure Build Test Labs Service Providers and Vendors Every vendor NTT: TBD Comcast: TBD Telefonica: TBD Testing Define Test Procedures Perform Tests Create Results & Lessons Learned All Every vendor: per device test S/w dev team? Owner: SP? 4

5 Meetings Team leads meeting: bi-weekly Team meeting: weekly Review & Planning Workshop April Review of 1 st half of Phase 1 and Planning of 2 nd half of Phase 1 Aug Review of Phase 1 and Planning workshop of Phase 2 Dec 2018 Review of 1 st half of Phase 2 and Planning of 2 nd half of Phase 2 Location ONF or suitable conference 5

6 Schedule Phase1 Point-to-Point Phase2 Mesh ROADM <Step1> - Integration of minimum set of devices - Control of terminal devices only - OpenConfig <Step2> - Expand to multiple devices - Control of terminal devices + OLS - OpenConfig <Step1> - Integration of minimum set of devices - Introduction of ROADM devices - OpenConfig, OpenROADM? Milestone at the end of Apr - P2P solution (apps and device drivers) - Integration report - Workshop leading to SP s lab trials - ONS & OFC outreach Milestone at the end of Aug - Revised P2P solution - Integration report - Workshop leading to SP s lab trials Jan Feb Mar Apr May June July Aug Sep Milestone at the end of Dec - Mesh solution - Integration report - Workshop leading to SP s field trials Oct Nov Dec ODTN Kickoff ONS talk OFC talk Result & Plan Workshop Result & Plan Workshop ECOC Result & Plan Workshop Dev & integration Initial devices + α Dev & interchangeability test + additional devices Dev & integration TBD ONOS TST & Dynamic Config Brigade ONOS N Release Share gaps and additional requirements Share gaps additional requirements ONOS O Release ONOS P Release ONOS Q Release 6

7 Test Lab Locations 1. Individual Device Test with ONOS (directly pass-through device config) At Vendors site (prior to shipping to operator s lab) Nokia offers VPN access during dev&test 2. Integration & Test NTT Palo Alto Office Telefonica Comcast: multiple options 7

8 Project Management Tools Wiki Start full read/write accessibility to the public, reconsider when issues arise JIRA Mailing List Slack Software ONOS uses Git for code repository, Gerrit for reviews All code contributions go into ONOS main repo (no private repo s, no closed source, ) 8

9 Technical Scope of Work ODTN 9

10 Outline for Scope of Work Scope and Scenarios Testing Reference Implementation T-API as NB Device APIs Apps Discussion 10

11 Phase 1 Scope: Point-to-Point Open Line System with Open APIs Goal Integrate ONOS and OLS devices with a simple P-to-P topology by using open APIs (OpenConfig) Build and verify the reference implementation for P-to-P use case Identify problems to be solved Device Components OpenConfig Transponder OLS: T-API? (only considered in step 2 of phase) Term Jan Aug 2018 API TRN MUX WSS AMP API WSS MUX TRN API 11 Open Line System (OLS)

12 Ground Rules There will be a few design choices we need to make For each point, we want consensus from 2 perspectives in a perfect world, how would we design it? what is a realistic option? This hopefully gives us guidance to choose when we have multiple options 12

13 Basic Scenario Types / Use Cases Path setup / Path teardown What kinds of paths should be covered? What are the failure scenarios we will cover? Out of Scope In Scope Operational Phase Initial Node Set up (Management IP address, Syslog, NTP, etc) Line set up (between line ports) Path Set up (between client ports) 13

14 Phase 1 Devices Device Type Scope for Phase 1 Parameters configured by ONOS Transponder Port, single wavelength Mux/Demux not configurable WSS Port, multiple wavelength Optical Amplifier Not mandatory for Phase 1 - Optical power signals may be configured but out of scope for Phase 1, as optical power optimization is required for long-haul but not for middle distance DCI use. TRN MUX WSS AMP WSS MUX TRN Open Line System (OLS) 14

15 Topology Test Plan Test scenarios and procedures TBD by Test Team Devices for Phase 1 Transponder OLS OpenConfig Model Ciena?? Infinera? Infinera? Nokia Lab Nokia Lab Open ROADM Model Fujitsu 1finity Lab NTT Palo Alto (also supports OpenConfig) Fujitsu 1finity Lab Coriant G30 Transponder (OpenConfig or Open ROADM?) ZTE? NEC? 15

16 Reference Implementation Architecture As agreed at the workshop in Oct 2017, we will mainly use ONOS Dynamic Configuration Subsystem and related tools (1) Service Model T-API YANG Compiler *.yang Service Design Orchestrator YANG Runtime RESTCONF NB JSON / XML (2) NB Protocol Distributed Config Store model.jar Service Application Dynamic Config Subsystem /devices /services *.yan g NETCONF SB (4) Protocol (6) Framework Open Config JSON / XML Open ROADM Device Device Device Device (3) Device Model (5) Data Plane 16

Transport API Transport API Functional Architecture Application NE NE SDN NE NE Controller Transport API Topology Service Connectivity Service Path Computation

17 Transport API Transport API Functional Architecture Application NE NE SDN NE NE Controller Transport API Topology Service Connectivity Service Path Computation Service Virtual Network Service Notification Service Shared Network Information Context Other SBIs Network Resource Groups NE Transport API SDN NE NE Controller 17

Transport API Transport API Functional Architecture Application NE NE SDN NE NE Controller Transport API Used for Phase 1 Topology Service Connectivity Service Path

18 Transport API Transport API Functional Architecture Application NE NE SDN NE NE Controller Transport API Used for Phase 1 Topology Service Connectivity Service Path Computation Service Virtual Network Service Notification Service Shared Network Information Context Other SBIs Network Resource Groups NE Transport API SDN NE NE Controller 18

19 Transport API Pinning down which subset of parameters to support in Connectivity Services, etc. is TBD by Use Case team Example of transponder TAPI Models for Phase 1 (1) NodeEdgePoint (Edge) NodeEdgePoint (Internal) ServiceInterfacePoint ConnectionEndPoint TRPD 1 Connection TRPD 2 Topology Node Mapping Connectivity Service Link Transitional Link Connection 25 19

20 Device API/model Pinning down which subset of models & parameters required for service provisioning is TBD by Use Case team OpenConfig Open ROADM If initial device configuration (management IP, etc.) is outside these models, each vendor needs to identify required models & parameters 20

21 Software Development Team: Development Items Orange Box service application mapping TAPI into OpenConfig/Open ROADM Details described in the following slides ONOS TAPI JSON Protocol Handling (e.g., REST, RESTCONF) Orange box Model-Agnostic POJO TAPI POJO DCS Change event notification & model fetch YANG Tools Missing features of Dynamic Configuration Subsystem and related codes Update / Replace Operations not implemented Transactional Operation & Rollback Bidirectional Configuration Synchronizer Understand the semantics. e.g., - logical to physical mapping - ServiceInterfacePoint to physical device port, etc. - extract parameter & constraints Compute abstract device configuration [Open Discussion points 1] e.g., - compute path to fulfil the request based on current topology and resource state Derive concrete device configuration (& apply) [Open Discussion point 2, 3] e.g., - determine device s model - map abstract device configuration to each device s model - send each device s configuration model to Devices Open Discussion points 1 How to compute device configurations? - Map to ONOS information model then compute? or not. - Leverage Intent F/W? - Leverage external PCE, e.g., TIP PSE, etc? Open Discussion points 2 How to derive concrete configuration? - Leverage Driver/Behaviour subsystem? or hand craft directly in orange box? Open Discussion points 3 How to deliver concrete configuration to Device? - via DCS - via Behaviour & SBI directly 21 to Device somehow

22 Software Development Team: Orange Box Design 1 How to compute device configurations? ~= compute path and variable parameters for each devices based on requested inputs All other ONOS applications, not using DCS, leverages ONOS abstract information model. This allows application logic for constrained path computation, etc. to be decoupled from each device protocol/api/model. e.g., Intent F/W, etc. Challenge is currently information model is mostly packet layer oriented Regardless of using ONOS information model or not, conversion to some form of common model will be required to externalize path computation process from application logic. (e.g., use TIP PSE, etc.) 22

23 Software Development Team: Orange Box Design 2 How to derive concrete configuration? = generate device specific configuration model given parameter per device is know ONOS currently has Driver/Behaviour mechanism as SB abstraction layer. This will allow hiding the details of difference in protocol/api/model/version Device speaks To leverage this feature we need to define Behaviour functional aspect of configuration we want to apply to devices e.g., tune port power, observe port power, 23

24 Example: ONOS Driver/Behaviour mechanism Current driver Behaviours: Request to configure certain aspect of device Behaviour interface def. Behaviour implementation Semantic mapping to config/message/model Do we want to explore platform extension option like these? Top half Behaviour Semantic mapping to config/message/model instruction aggregation layer abstraction layer to deal with semantically similar but different models e.g., revision or version difference Transport handling (add envelope, etc.) communicate with device using appropriate protocol/model Bottom half Behaviour Transport handling (add envelope, etc.) ~= DCS

25 Software Development Team: Orange Box Design 3 How to deliver concrete configuration to Device? DCS currently has some level of NETCONF support to the south. In other parts ONOS Driver/Behaviour mechanism is used to hide SB protocol differences If we need to deal with non-netconf protocol, how to deliver the model to the Device. Irrelevant if we only use NETCONF/XML 25

26 Action Items Due Today Team member assignment Pick suitable meeting timeslot for each teams & start dates Define work item until the first team meeting e.g., sketch of time line Start initial team discussion if there s time left 26

27 Backup slides 27

28 TAPI Models for Phase 1 (1) Example of transponder NodeEdgePoint (Edge) NodeEdgePoint (Internal) ServiceInterfacePoint ConnectionEndPoint TRPD 1 Connection TRPD 2 Topology Node Mapping Connectivity Service Link Transitional Link Connection 28

29 TAPI Models for Phase 1 (2) Example of WSS NodeEdgePoint (Edge) NodeEdgePoint (Internal) ServiceInterfacePoint ConnectionEndPoint ROAD M1 Connection ROAD M2 Topology Node Mapping Link Connectivity Service Transitional Link Connection 29

30 TAPI Models for Phase 1 (3) Example of transponder and WSS TRPD 1 TRPD 2 NodeEdgePoint (Edge) NodeEdgePoint (Internal) ServiceInterfacePoint ConnectionEndPoint Topology Node Mapping Link ROAD M1 ROAD M2 Transitional Link Connection 30

31 Sequences to set up a path with TAPI 1. Register TAPI s Context models to ONOS in advance 2. TAPI Client sends a ConnectivityService request to set up a path 3. ONOS creates Connection in response to the ConnectivityService 4. ONOS creates OpenConfig device model(s) or Open ROADM device model(s) calculated by ONOS based on Connection model 5. ONOS sends a Netconf message to each device with the OpenConfig model or the Open ROADM model 31

32 1. Register TAPI s Context models to ONOS in advance TAPI Client ONOS DC Store Register models NodeEdgePoint (Edge) NodeEdgePoint (Internal) ServiceInterfacePoint ConnectionEndPoint TRPD 1 TRPD 2 TAPI Models in ONOS Topology Node Mapping Link Transitional Link Server 1 Transponder 1 Transponder 2 Server 2 Devices Connection 32

33 2. TAPI Client sends a ConnectivityService request to set up a path TAPI Client ConnectivityService Request (RESTCONF) ONOS DC Store NodeEdgePoint (Edge) NodeEdgePoint (Internal) ServiceInterfacePoint ConnectionEndPoint TRPD 1 TRPD 2 TAPI Models in ONOS Topology Node Mapping Connectivity Service Link Transitional Link Server 1 Transponder 1 Transponder 2 Server 2 Devices Connection 33

34 3. ONOS creates Connection in response to the ConnectivityService TAPI Client ONOS DC Store NodeEdgePoint (Edge) NodeEdgePoint (Internal) ServiceInterfacePoint ConnectionEndPoint TRPD 1 Connection TRPD 2 TAPI Models in ONOS Topology Node Connectivity Service Mapping Link Transitional Link Server 1 Transponder 1 Transponder 2 Server 2 Devices Connection 34

35 4. ONOS creates OpenConfig device model(s) or Open ROADM device model(s) calculated by ONOS based on Connection model 5. ONOS sends a Netconf message to each device with the OpenConfig model or the Open ROADM model TAPI Client ONOS DC Store NodeEdgePoint (Edge) NodeEdgePoint (Internal) ServiceInterfacePoint ConnectionEndPoint TRPD 1 Connection TRPD 2 TAPI Models in ONOS Topology Node Connectivity Service Mapping Link Transitional Link Server 1 Transponder 1 Device Config(NETCONF) Transponder 2 Server 2 Devices Connection 35

36 Discussion: gnmi for SBI? Some devices support not NETCONF but gnmi for SBI protocol Current Dynamic Configuration Subsystem of ONOS supports only NETCONF for SBI protocol Do we support gnmi as well as NETCONF? - Need to find ways to develop it with Software Development Team 36

37 Internal Sequence with Dynamic Configuration Subsystem *.yang Load TAPI YANG Already done YANG Compiler model.jar Generate TAPI.jar Device Certification App Device Config App REST / RESTCONF NB Read TAPI Network jar & Generate Function NBI(RESTCONF) Handle NBI Event notification and Generate TAPI Model based Java objects Expected to work with the existing codes, but need to be confirmed YANG Runtime Generate OpenConfig/ OpenROADM jar Dynamic Config Subsystem Read OpenConfig/Open ROADM based Jar and generate SBI With generated Java objects, translate TAPI-based Service Model to OpenConfig or Open ROADM based Device Model Store Device Model and notify SBI Needed to development model.jar NETCONF SB Distributed Config Store YANG Compiler *.yang Device Device /devices Request device configuration to NE via Device Netconf protocol /services Load OpenConfig OpenROADM YANG Device Device Device Device Device Device 37

38 Service Application Mapping between Service Request to Device Configuration 1. Understand semantics of request 2. Do path computation, constraint handling, 3. Generate individual device configuration 38

39 Test Items 1. Test the ONOS driver (without T-API based NBI) with vendors devices Test if device configuration based on OpenConfig/Open ROADM Yang Models can be install to each vendor s device to verify YANG runtime functionality Test if signal communication passes through a configured path 2. Integration Test Test if device configuration can be sent into multiple devices across a network NBI YANG: T-API, Protocol: RESTCONF SBI YANG: OpenConfig / Open ROADM, Protocol: NETCONF Test if signal communication passes through a configured path Data plane performance test is not in scope Test procedures are TBD by Test team 39

ODTN An Open Controller for the Disaggregated Optical Network

ODTN An Open Controller for the Disaggregated Optical Network Andrea Campanella andrea@opennetworking.org An Operator Led Consortium Outline Clear ask from Operators ONOS as a Platform Incremental steps