1 / 18

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

pete
Download Presentation

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. 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 Setsas a consequence: • => Duplicated information • => Lacks logical organization inside Optical Node LSAs We propose two modifications to improve the solution indraft-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 • <Node Attribute> ::= <ConnectivityMatrix>... <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): • Node attribute LSA containing ConnectivityMatrix that indicates: •               - (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 constraintsEverything inside Node Attribute LSA Question to WG: Accept these modifications?

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

  8. Item 1 - Layout of an Optical Node Property LSABelow 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 • 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 : • +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  11. 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 : • +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  12. Technical context – What needs to be advertised about WSON nodes B A A C C Ingress ports Egress ports D D OEO resources Connectivity matrixdepicts 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 signalregeneration

  13. B 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) A A C C Egress ports Ingress ports D D OEO resources 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. drop add … Tun. Drop Tun. Drop … OEO pool Fully flexible Y-node with 1 pool of O-E-O From node A To node A From node B To node B From node C To node C With higher degree nodes (e.g. connectivity = 8): Multiple pools are really likely to appear (depends on add-drop traffic)

  15. Tun. Drop Tun. Drop Tun. Drop OEO pool 1 OEO pool 2 OEO pool 3 OEO pool 4 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 From node C

  16. Documents context Scope: Connectivity constraints in nodesand labels usage in links Scope: OEO equipments and their usage in RWA draft-ietf-ccamp-rwa-wson-framework-07(gone through last-call) draft-ietf-ccamp-rwa-info-11 draft-ietf-ccamp-general-constraint-encode-04 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)

More Related