1 / 10

Giovanni Martinelli, Julien Meuric, Pierre Peloso

OSPF-TE Extensions for WSON-specific Network Element Constraints draft-peloso-ccamp-wson-ospf-oeo-02. Giovanni Martinelli, Julien Meuric, Pierre Peloso. Rationales for WSON work in ccamp.

vartan
Télécharger la présentation

Giovanni Martinelli, Julien Meuric, Pierre Peloso

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. OSPF-TE Extensions for WSON-specific Network Element Constraintsdraft-peloso-ccamp-wson-ospf-oeo-02 Giovanni Martinelli, Julien Meuric, Pierre Peloso

  2. Rationales for WSON work in ccamp Target:Flooding of information through OSPF-TE to provide a graph to compute both spatial and spectral assignment of a LSP into an all-optical meshed network (WSON). Issues to solve:Not only flooding of wavelength availability inside links, but also: • Switching constraints (spatial and spectral) inside nodes (between links) • Description of O-E-O resources inside nodes (for regeneration or conversion purposes) • Their availability • Their features • Their accessibility

  3. Changes since 01 • Demand from the chairs to merge with drafts: • draft-ietf-ccamp-wson-signal-compatibility-ospf • draft-zhang-ccamp-rwa-wson-routing-ospf-03 see draft tree next slide

  4. Documents tree concerning RWA draft-ietf-ccamp-rwa-wson-framework-07(gone through last-call) draft-ietf-ccamp-rwa-info-09 Scope: Connectivity constraints in nodesand labels usage in links draft-ietf-ccamp-general-constraint-encode-03 draft-zhang-ccamp-general-constraints-ospf-ext-00 draft-ietf-ccamp-rwa-wson-encode-06 Scope: OEO equipments and their usage in RWA draft-ietf-ccamp-wson-signal-compatibility-ospf-02 draft-peloso-ccamp-wson-ospf-oeo-02 OVERLAPS?

  5. Status on works to reach convergence • First, acknowledge the policy of separation between generic and WSON-specific extensions • Second separate items into two categories: • What was commonly agreed • This stuff ended in draft-zhang-ccamp-general-constraints-ospf-ext-00 • Items with some technical divergences • This stuff is kept separated in current draft and the one presented just before Third conform to the framework documents and get aligned with the encoding drafts (while not being bonded by their content)

  6. How about mapping on TOP level TLVs? • No Concern about *what* information (well described in general/wson specific encoding) but how we pack them together. • Top Level TLVs • List of New sub-TLVs: • (General + WSON specific) TE-Link TLV rfc3036 Wson Sub-TLV Wson Sub-TLV Node-Address TLV rfc5786 Mapping Wson Sub-TLV Wson Sub-TLV Wson Sub-TLV Resource Block Attribute TLV Wson Sub-TLV • new Wson Sub-TLV Wson Sub-TLV

  7. B B A C A C D D Technical description of the OSPF-TE modifications – previous draft-ietf-ccamp-wson-signal-compatibility-ospf • Provide an OSPF-TE layout • Have LSA for WDM links with availability of wavelength (dynamic) • Have LSA for switching constraints of nodes and OEO resources (static and dynamic)

  8. B B A C A C OEO pool OEO pool OEO pool D D Technical description of the OSPF-TE modifications – current draft-peloso-ccamp-wson-ospf-oeo • Provide an OSPF-TE layout that intrinsically separates some static info from some dynamic ones, exploiting the concept of OEO pools • Have LSA for WDM links with availability of wavelength (dynamic) • Have LSA for switching constraints of nodes (static) • Have LSA for OEO resources (static and dynamic)

  9. Why introducing a new top-level TLV to have OEO specific LSA • 1. For the sake of OSPF-TE scalability • Smaller objects – independent – more easy to update • 2. To reach a certain degree of consistency in each LSA • One object (with a single stage of depth) describe the node switching constraints and all that is related • Another object (with a single stage of depth) describe the OEO pools features • 3. To re-use some TLVs of link LSA that make sense concerning OEO pools • SRLGs • TE-metric • Administrative group • 4. To keep the specific status of Node LSA (top-level TLV 5) which holds a specifically static content only – i.e. reference IP address.

  10. Questions and discussion?

More Related