1. 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

2. Problems faced with current drafts
Currently RWA model defines “Resource Block” (group of n OEOs)
same devices features
same accessibility constraints (ref to draft-ietf-ccamp-rwa-info)
RB is the only aggregation granularity inside the model => each piece of information each time refers to newly defined RB Sets as a consequence:
=> Duplicated information
=> Lacks logical organization inside Optical Node LSAs
We propose two modifications to improve the solution in draft-ietf-ccamp-rwa-info

3. Modification 1 - Changing structure of Optical Node Property LSA
Structure from draft-ietf-ccamp-rwa-info
<Optical Node Property LSA> ::= <ResourcePool>
<ResourcePool> ::= <RBInfo>... [<RBAccessibility>...] [<ResourceWvlConstraints>...] [<SharedAccessWvls>...] [<ResourcePoolState>]
Proposed structure
<Optical Node Property LSA> ::= <ResourceGroup>...
<ResourceGroup> ::= <RGroupID> (<RBInfo> [<RBState>])... [<RGAccessibility>] [<RGWvlConstraints>] [<SharedAccessWvls>]
With simplifications of
e.g.:<SharedAccessWvls> ::= <RBSet> [<SharedIngressWvl>] [<SharedEgressWvl>]
Implementation dependant a node may advertize multiple <Optical Node Property LSA>, each one containing a single <ResourceGroup>

4. Modification 2 - Way of advertizing connectivity constraints
<RBSet> : A Set of RB IDs
<LinkSet> : A Set of Link IDs (WDM links)
<IngressMixedSet> : A Set containing Links IDs and RG IDs
Functioning of draft-ietf-ccamp-rwa-info
<Node Attribute> ::= <ConnectivityMatrix>...
<ConnectivityMatrix> ::= (<IngressLinkSet> <EgressLinkSet>)...
<Optical Node Property> ::= <X>... <Y>... <RBAccessibility>...
<RBAccessibility> ::= <PoolIngressMatrix> <PoolEgressMatrix>
<Pool_____Matrix> ::= (<LinkSet> <RBSet>)...
Proposal: Advertizing MixedSet of Links and RGroups
<ConnectivityMatrix> ::= (<IngressMixedSet> <EgressMixedSet>)...
Consequently a ResourceGroup (modification 1) becomes:
<ResourceGroup> ::= <RGroupID> (<RBInfo> [<RBState>])... [<RGAccessibility>] [<RGWvlConstraints>] [<SharedAccessWvls>]

5. Illustration of our proposition:
draft-ietf-ccamp-rwa-info (24 elements ID – info spread over two LSAs):
Node attribute LSA containing ConnectivityMatrix that indicates:
              - (Entering interfaces A and C) to (outgoing interfaces X and Z)
              - (Entering interfaces B, D and E) to (outgoing interfaces X, Y and K)
Node property LSA containing ResourceAccessibility that indicates:
       - It is possible to interconnect:
               - (RG1)     to     (entering interfaces A and C)
               - (RG1)     to     (outgoing interfaces X and Z)
               - (RG2)     to     (entering interfaces B, D and E)
               - (RG2)     to     (outgoing interfaces X, Y and K)
Our proposal (14 elements ID – info gathered):
              - (Entering A, C and RG1)     to     (outgoing X, Z and RG1)
              - (Entering B, D, E and RG2)     to     (outgoing X,Y, K and RG2)

6. Conclusion Presented:
Proposed a new info modeling of WSON Nodes Introducing Resource Groups
Proposed the grouping of connectivity constraints Everything inside Node Attribute LSA
Question to WG:
Accept these modifications?

7. Questions, discussions and directions?
7 | OSPF-TE extensions for WSON | IETF 79th

8. Item 1 - Layout of an Optical Node Property LSA Below draft-ietf-ccamp-rwa-info layout
<Optical Node Property LSA> ::= [<ResourcePool>]
<RBSet> : A Set of RB IDs
<LinkSet> : A Set of Link IDs (WDM links)
<ResourcePool> ::= <RBInfo>... [<RBAccessibility>...] [<ResourceWvlConstraints>...] [<SharedAccessWvls>...] [<ResourcePoolState>]
<RBInfo> ::= <RBSet> <InputConstraints> <ProcessingCapabilities> <OutputConstraints>
<_____Constraints> ::= <ModulationTypes> [<BitRates>] <FECTypes> [<ClientTypes>]
<ProcessingCapabilities> ::= number of devices in the RBlock + specific capabilities
Means that each time you have a “group” of same devices of different size you have to define a new <RBInfo> then expanding this list
<RBAccessibility> ::= <PoolIngressMatrix> <PoolEgressMatrix>
<Pool_____Matrix> ::= (<LinkSet> <RBSet>)...
<ResourceWvlConstraints> ::= <RBSet> [<IngressWvlCnstrts>] [<EgressWvlCnstrts>]
<SharedAccessWvls> ::= <RBSet> [<SharedIngressWvl>] [<SharedEgressWvl>]
<ResourcePoolState> ::= <RBSet> <RBUsage> (number of OEO devices used per RB)
Duplicated RBSets

9. Proposition 1.A: Creating a ResourceGroup entity - Group of RBs sharing same accessibility constraints
<Optical Node Property LSA> ::= [<ResourceGroup>...]
<LinkSet> : A Set of Link IDs (WDM links)
<ResourceGroup> ::= <RGroupID> (<RBInfo> <RBState>)... [<RGAccessibility>] [<RGWvlConstraints>] [<SharedAccessWvls>]
<RBInfo> ::= <InputConstraints> <ProcessingCapabilities> <OutputConstraints>
<_____Constraints> ::= <ModulationTypes> [<BitRates>] <FECTypes> [<ClientTypes>]
<ProcessingCapabilities> ::= number of devices in the RBlock + specific capabilities
<RBState> ::= number of devices used
<RGAccessibility> ::= <IngressLinkSets> <EgressLinkSets>
<RGWvlConstraints> ::= <IngressWvlCnstrts> <EgressWvlCnstrts>
<SharedAccessWvls> ::= <SharedIngressWvl> <SharedEgressWvl>
Implementation dependant a node may advertize multiple <Optical Node Property LSA>, each one containing a single <ResourceGroup>

10. TLVs: ConnectivityMatrix vs ResourcePoolAccessibility
| Connectivity | MatrixID | Reserved |
| Ingress Link Set A # |
: : :
| EgressLink Set B # :
| Additional Link set pairs as needed |
: to specify connectivity :

11. TLVs: ConnectivityMatrix vs ResourcePoolAccessibility
| Connectivity | Reserved |
| Ingress Link Set Field A # |
: :
| RB Set Field A # |
| Additional Link set and RB set pairs as needed to |
: specify PoolIngressMatrix :
| Egress Link Set Field B # |
| RB Set B Field #1 (for egress connectivity) |
| Additional Link Set and RB set pairs as needed to |
: specify PoolEgressMatrix :

12. Technical context – What needs to be advertised about WSON nodes
Ingress ports C
Egress ports D D
OEO resources
Connectivity matrix depicts constraints between ingress and egress ports
OEO resources depicted by:
Accessibility constraints with ingress and egress ports
OEO devices features (bit-rate, etc…)
OEO : Optic-Electronic-Optic (HW devices) achieve wavelength conversion and signal regeneration

13. Importance of OEO pools
Currently RWA model defines “Resource Block” (group of n OEOs)
same accessibility constraints
same features (ref to draft-ietf-ccamp-rwa-info) B A A C
Egress ports C
Ingress ports D
OEO resources D
RB1: 5x10Gbit/s
RB2: 7x40Gbit/s
RB3: 3x43Gbit/s
New element of model:
Resource pool (group of m RBlocks) with same accessibility constraints
RB4: 11x10Gbit/s
RB5: 5x40Gbit/s
RB6: 3x43Gbit/s
RB7: 9x10Gbit/s
RB8: 1x43Gbit/s
Requirement: Provide model support for OEO pools which are logical entities inside WSON nodes – used by operation teams

14. Fully flexible Y-node with 1 pool of O-E-O
From node A
To node A
add
drop …
Tun.
Drop
From node B
To node B
From node C
To node C
OEO pool
With higher degree nodes (e.g. connectivity = 8):
Multiple pools are really likely to appear (depends on add-drop traffic)

15. Fully flexible Y node with 4 pools of O-E-O fixed to links
To node A
From node A
To node B
From node B
To node C
Tun.
Drop
From node C
OEO pool 4
OEO pool 2
OEO pool 3
OEO pool 1

16. draft-ietf-ccamp-rwa-wson-framework-07 (gone through last-call)
Documents context
draft-ietf-ccamp-rwa-wson-framework-07 (gone through last-call)
draft-ietf-ccamp-rwa-info-11
Scope: Connectivity constraints in nodes and labels usage in links
draft-ietf-ccamp-general-constraint-encode-04
Scope: OEO equipments and their usage in RWA
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00
draft-ietf-ccamp-rwa-wson-encode-11
draft-ietf-ccamp-wson-signal- compatibility-ospf-04
draft-peloso-ccamp-wson-ospf-oeo-02
Back in Beijing - Alternative solutions

17. From IETF 79th Chairs concluded last meeting by :
Are all requirements well considered?
Are divergences coming from OSPF drafts or higher in draft-tree?
Since then, a collective decision:
Connectivity matrix inside -> Node Attribute top-level TLV
OEO related TLVs inside -> new top-level TLV: Node Property
Afterwards, further discussions on:
The structure of Node Property top-level TLV, with following issues:
Misunderstanding on “pools”
Misunderstanding on separation between generic and wson-specific

18. Proposition 1.B: Creating a ResourceGroup entity - Group of RBs sharing same accessibility constraints
<Optical Node Property LSA> ::= [<ResourcePool>]
<RBSet> : A Set of RB IDs
<LinkSet> : A Set of Link IDs (WDM links)
<ResourcePool> ::= <ResourceGroup>... <RBInfo>... <ResourcePoolState>
<ResourceGroup> ::= <RGroupID> <RBSet> <RGAccessibility> <RGWvlConstraints> <SharedAccessWvls>
<RGAccessibility> ::= <IngressLinkSets> <EgressLinkSets>
<RGWvlConstraints> ::= <IngressWvlCnstrts> <EgressWvlCnstrts>
<SharedAccessWvls> ::= <SharedIngressWvl> <SharedEgressWvl>
<RBInfo> ::= <RBSet> <InputConstraints> <ProcessingCapabilities> <OutputConstraints>
<_____Constraints> ::= <ModulationTypes> [<BitRates>] <FECTypes> [<ClientTypes>]
<ProcessingCapabilities> ::= number of devices in the RBlock + specific capabilities
<ResourcePoolState> ::= <RBSet> <RBUsage> (number of OEO devices used per RB)