1. Standardisation Activities on Flexigrid Adrian Farrel - Old Dog Consulting adrian@olddog.co.uk ECOC 2013 – London, September 2013 Old Dog Consulting

2. Why standardise? • Standardisation makes things work better • Interoperability • Standardisation means you know what you are buying • The product fulfils the publically-available specification • Standardisation means you know what to make • The requirements and specification have been thought through and published

3. Why standardise? • Plug-and-play compatibility is largely a myth in optical networks • Every vendor has optical secret source • Some potential at the optical edge • Potential of common control plane across multiple vendors • Benefits to component manufacturers • Hardware and software • Comoditisation • Streamlined development costs • Pooled learning curve and debugging • Operational, training, and research advantages • Common elements across platforms and networks • Staff skills are portable

4. Standardisation outcomes for FP7 Projects • Increasing demand for “standardisation” as an outcome of EC-funded projects • Why does the Commission care? • It is a measurable outcome • How many standards? • It provides external verification • The commercial world has validated the project work • It is a valuable shared product • The standards disseminate the project work • It shows thought-leadership from within Europe • Why should the participants care? • It is a way of getting (free) input to the project • …and all the above

5. Standardisation Mechanisms and Paradigms • Standardisation is a cooperative process • Don’t expect a rubber stamp on your private work • Do expect critical review and modification • Standardisation is not a rapid process • Everything is done in the right order and with the right amount of review • Don’t under-estimate the value of implementation • “Running code” • Take your work to the right standards body • Seek out the experts and get critical review • Don’t fuel “turf wars” • Look for open standards processes • Open for participation • Open work practices • Freely available output

6. Standardisation in IDEALIST • IDEALIST aims at developing data and control plane solutions based on elastic networks enabling adaptive network and service interworking • Includes (is built on) use of flexigridstart • Project proposal 2011 • Project November 2012 • Standardisation from day one • Often left to the end of the project • Very little chance of successful completion • Leads to rushed work and a demand for a “rubber stamp” • Causes the project work to carry on, sometimes for years • IDEALIST puts standardisation as a key and early outcome • Stated in the project proposal • An immediate focus • Work actually started as soon as the proposal was put together

7. Flexigrid Data Plane Standardisation • Data plane • Main work already completed before project start • ITU-T Recommendation G.671 • "Transmission characteristics of optical components and subsystems“ (2009) • ITU-T Recommendation G.694.1 (revision 2) • "Spectral grids for WDM applications: DWDM frequency grid" (February 2012) • ITU-T Recommendation G.694.2 • "Spectral grids for WDM applications: CWDM wavelength grid“ (December 2003) • Key formulae • Frequency (THz) = 193.1 THz + n * frequency granularity (THz) • Frequency granularity for the flexible grid is 0.00625 THz • Slot Width (GHz) = 12.5 GHz * m

8. Flexigrid Control Plane (1 of 3) • Active work is in the CCAMP working group of the IETF • Framework and Requirements for GMPLS based control of Flexi-grid DWDM networks • draft-ogrcetal-ccamp-flexi-grid-fwk • Work from 13 companies and organisations • Work started in July 2012 • Just being adopted by the working group as a formal work item • General discussion of building-blocks • Switching capabilities • TE links • Network layering • Path computation

9. Flexigrid Control Plane (2 of 3) • Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers • draft-farrkingel-ccamp-flexigrid-lambda-label • Work started in October 2011 • Defines the core control plane concept of a label • Building on RFC 6205 Generalized Labels for Lambda Switching 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. | Identifier | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | m | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • Grid = 3 = ITU-T Flex (new value) • Channel Spacing = 5 = 6.25 GHz (new value) • Identifier = laser/port identifier per RFC 6205 • Frequency (THz) = 193.1 THz + n * frequency granularity (THz) per RFC 6205 • Slot Width (GHz) = 12.5 GHz * m

10. Flexigrid Control Plane (3 of 3) • RSVP-TE Signaling Extensions in support of Flexible Grid • draft-zhang-ccamp-flexible-grid-rsvp-te-ext • Work started in October 2011 • Examining the RSVP-TE requirements and extensions for Flexigrid • Remarkably little work needed • Use label from draft-farrkingel-ccamp-flexigrid-lambda-label • New traffic parameter format • Sender-Tspec • Flowspec • GMPLS OSPF-TE Extensions in for Flexible Grid DWDM Networks • draft-zhang-ccamp-flexible-grid-ospf-ext • Work started in October 2011 • OSPF requirements and extensions for Flexigrid • Main issue is how to represent and advertise available slots on a link • Label range (inclusive/exclusive) • Label list (inclusive/exclusive) • Bitmap

11. Questions adrian@olddog.co.uk