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

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

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>

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>]

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)

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?

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

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

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>

TLVs: ConnectivityMatrix vs ResourcePoolAccessibility 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connectivity | MatrixID | Reserved | | Ingress Link Set A #1 | : : : | EgressLink Set B #1 : | Additional Link set pairs as needed | : to specify connectivity :

TLVs: ConnectivityMatrix vs ResourcePoolAccessibility 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connectivity | Reserved | | Ingress Link Set Field A #1 | : : | RB Set Field A #1 | | Additional Link set and RB set pairs as needed to | : specify PoolIngressMatrix : | Egress Link Set Field B #1 | | RB Set B Field #1 (for egress connectivity) | | Additional Link Set and RB set pairs as needed to | : specify PoolEgressMatrix :

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

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

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)

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

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

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

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)