1 / 22

MAINS (Metro Architectures enablINg Subwavelengths)

MAINS (Metro Architectures enablINg Subwavelengths). WP2 Metro architectures exploiting optical packet/flow switching. Mark Basham(WPL, INT) George Zervas(UESSEX) MAINS 2 nd EC Technical Review Brussels, March 29 th 2012. Contents. Brief WP2 summary

moriah
Download Presentation

MAINS (Metro Architectures enablINg Subwavelengths)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. MAINS (Metro Architectures enablINg Subwavelengths) WP2 Metro architectures exploiting optical packet/flow switching Mark Basham(WPL, INT) George Zervas(UESSEX) MAINS 2nd EC Technical Review Brussels, March 29th 2012

  2. Contents • Brief WP2 summary • Objectives, activities and Y2 results • Technical insight on Y2 results • XML Control Plane APIs • OAM architecture for subwavelength networks

  3. Main WP2 objectives [Y1] Specification & Design of Physical Network and Node Architecture • OPST Ring • TSON Mesh [Y2]Specification & Design of Control Plane Architecture • OPST XML #1 • TSON XML #2 • GMPLS XML #3 [Y2] Common OAM Proposal for Subwavelength networks

  4. Activities breakdown Y1 Y2 Y2 Y2 Y1 Y2

  5. WP2 workplan M15 Published XML#1 Network Control Interface document Y2 M15 Published XML#2 Network Control Interface document M19 OAM specification proposal M18 Published XML#3 Network Control Interface document

  6. Y2 work summary & main results • Starting points of work • Definition of network scenarios, drivers and requirements for metro-regional architectures combining optical transport and network resident IT resources (T1.1, D1.1) • OPST Metro Network Design and Control Plane requirements (T2.1, D2.1) • TSON Metro Network Design and Control Plane requirements (T2.2, D2.3) • Y2 efforts predominantly employed • Specifying XML control plane APIs (T2.1 + T2.2 + T2.3) • OAM architecture for subwavelengthnetworks (T2.4) • Main Y2 results • XML #1 OPST Control Plane API (T2.1, D2.2) • XML #2 TSON Control Plane API (T2.2, D2.4) • XML #3 GMPLS Control Plane API (T2.3, D2.5) • OPST & TSON Common OAM Proposal (T2.4, D2.6)

  7. WP2: Y2 Delivering Operational Control Year 1 Results Year 2 Results D2.2 XML #1 OPST Control Plane API WP3 D2.1 OPST Metro Network Design D2.5 XML #3 GMPLS Control Plane API D2.6 OPST & TSON Common OAM Proposal WP1 WP1 D2.3 TSON Metro Network Design WP4 D2.4 XML #2 TSON Control Plane API Three XML control plane interfaces specified and in production. To be demonstrated in WP4

  8. New data plane technology Time Shared Optical Network (TSON) as metro mesh network architecture for guaranteed, statistically-multiplexed services

  9. Control Plane Architecture • A two-fold control plane solution composed of vertically interoperable GMPLS CP and Subwavelength CP is proposed. • The supervising upper-layer GMPLS CP provides the end-to-end resource reservation and routing across multiple sub-wavelength technologies. • A vertical cooperation between the Subwavelength CP and GMPLS CP through XML interface is proposed to deliver a transport-agnostic GMPLS, which can more flexibly support any sub-wavelength switching solution.

  10. XML Control Plane APIs • Network gets an IT interface • XML is • W3C International standard, endorsed by software industry • Software & Platform Independent • Flexible and lower cost approach - Telco specific expertise not required • XSLT option for native sub wavelength variants

  11. OPST & TSON Control Plane OPST The sub-wavelength connection is specified by the edge ports and the bandwidth parameters. The routing across internal ports and the scheduling mechanism are handled by the internal OPST control plane and not exposed to the GMPLS control system. TSON The sub-wavelength connection is specified by the edge (tributary) ports and bandwidth parameters, but additionally the scheduling and route via the internal ports of the network are also provisioned

  12. XML 1, 2 & 3 API Documentation

  13. XML # 1 – 25 Use Cases Modelled

  14. XML # 2 – 20 Use Cases Modelled

  15. XML # 3 – 21 Use Cases Modelled

  16. Channel reservation type in XML schema definition • This generic representation of a channel enables us to define resources for fixed/flexible time/frequency based networks as in TSON and FSON. The channel type is one of the main attributes on every port, carrying information between data plane and control plane units.

  17. XML introduced at the Network level • Believed to be the first implementation of XML in the telecom management/control plane • Will aid flexibility and lower cost of integration and service development • Convergence of IT and Telecom • Opens Telecom to practices and economies of IT • 3XML Interfaces specified and in development

  18. OAM architecture for subwavelength networks • A new E2E architecture enabling MPLS and subwavelength OAM interworking. • OAM architecture within a single OPST and TSON subwalength domains • Novel performance monitoring mechanism enabling scalable OAM flows in E2E network architectures.

  19. OPST OAM functions

  20. TSON hierarchical OAM functions

  21. MAINS performance monitoring proposal • Continuity check and Connectivity Verification (CC-V): scalability could be assured by applying Label stacking in our E2E OAM architecture. • Delay Measurement (DM): we propose a train of packets which, on the one hand, aims to provide enough accuracy (i.e relative error below 0,2) for E2E jitter estimations and on the other hand to minimize the amount of OAM traffic injected in the networkof • Loss Measurement (LM): • For “low frequency” background loss probability estimation one could send a single LM packet every 10 seconds, which yields 8640 packets per day. • For on-demand LM due to noticeable packet drop at the user level a packet train of length 100 should suffice. • Throughput measurement: we choose 100 packets as a good balance between measurement accuracy and isolation of the rest of the traffic in the LSP.

  22. Summary • WP2 activities are completed • Main objectives for year 2 are achieved: • XML interfaces • E2E OAM architecture

More Related