ospf-te extensions for wson-specific network element constraints draft-peloso-ccamp-wson-ospf-oeo-02...

OSPF-TE Extensions for WSON-specific Network Element Constraints

draft-peloso-ccamp-wson-ospf-oeo-02

Giovanni Martinelli, Julien Meuric, Pierre Peloso

draft-peloso-ccamp-wson-opsf-oeo-022 | OSPF-TE extensions for WSON | IETF 79th

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


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


Documents tree concerning RWA

draft-ietf-ccamp-rwa-wson-framework-07(gone through last-call)

draft-ietf-ccamp-rwa-info-09

draft-ietf-ccamp-rwa-wson-encode-06

draft-ietf-ccamp-general-constraint-encode-03

draft-ietf-ccamp-wson-signal-compatibility-ospf-02

draft-zhang-ccamp-general-constraints-ospf-ext-00

draft-peloso-ccamp-wson-ospf-oeo-02OVERLAPS?

Scope: OEO equipments and their usage in RWA

Scope: Connectivity constraints in nodesand labels usage in links


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)

draft-peloso-ccamp-wson-opsf-oeo-02

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.

6 | OSPF-TE extensions for WSON | IETF 79th

TE-Link TLV

rfc3036

Node-Address TLV

rfc5786

Resource Block

Attribute TLV

Wson Sub-TLV

Wson Sub-TLV

Wson Sub-TLV

Wson Sub-TLV

Wson Sub-TLV

Wson Sub-TLV

Wson Sub-TLV

Wson Sub-TLV

List of New sub-TLVs: (General + WSON

specific)

Mappin

g

Top Level TLVs

new


A

B

C

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)

A

B

C

D


A

B

C

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)

A

B

C

D

OEO pool

OEO poolOEO pool


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.


Questions and discussion?