Presentation is loading. Please wait.

Presentation is loading. Please wait.

OSPF-TE extensions for OTN (draft-ashok-ccamp-gmpls-ospf-g709-03) CCAMP IETF-80 (Mar-2011) Rajan Rao Ashok Kunjidhapatham.

Similar presentations


Presentation on theme: "OSPF-TE extensions for OTN (draft-ashok-ccamp-gmpls-ospf-g709-03) CCAMP IETF-80 (Mar-2011) Rajan Rao Ashok Kunjidhapatham."— Presentation transcript:

1 OSPF-TE extensions for OTN (draft-ashok-ccamp-gmpls-ospf-g709-03) CCAMP IETF-80 (Mar-2011) Rajan Rao (rrao@infinera.com)rrao@infinera.com Ashok Kunjidhapatham (akunjidhapatham@infinera.com)akunjidhapatham@infinera.com John Drake (jdrake@juniper.net)jdrake@juniper.net Steve Balls (Steve.Balls@metaswitch.com)Steve.Balls@metaswitch.com Khuzema Pithewan (kpithewan@infinera.com)kpithewan@infinera.com Snigdho Bardalai (sbardalai@infinera.com)sbardalai@infinera.com Biao Lu (blu@infinera.com)blu@infinera.com

2 Outline Update Summary Path Computation – what we need Existing solutions looked at The Model – Examples – Encoding details Summary & Next Steps Comments & Response

3 Update Summary 1. Moved away from single ISCD to multiple ISCDs – One ISCD per ODU rate (as discussed in Beijing) 2.Identified new requirements – Muxing restrictions & service creation – Induced FAs & OTN multiplexing hierarchy – Consistency with RFC6001 3.Non OTN signal transport – Address ‘Termination’ capability for non-OTN transport over ODUs E.g. terminate ODU and extract Ethernet for packet switching at every node 3

4 Path computation – what is required Typical use cases Unbundled Te-LinksBundled Te-links ISCDsMux/Dmux info (IMCD) ISCDsMux/Dmux info (IMCD) LSP w/o FAYNYN LSP with Manual FAsYNYN VCAT w/o FAYNYN VCAT with Manual FAsYNYN nxLSPs w/o FAYNYN LSP with induced FAYYYY VCAT with induced FAYYYY nxLSPs with induced FAYYYY LSP for non OTN client transport (e.g. Pkt switching at every node with ODU termination) YYYY New challenges to address

5 Existing Mechanisms - Inadequate Role of IACD: – According to RFC 5212, IACD represents internal BW Two independent switch fabric model Relationship between only TWO layers/interfaces – We need to address the following for OTN muxing hierarchy Single switch fabric for all ODUs Multiple Layer (>2) relation, Muxing restrictions & disparities – e.g. ODU2-ODU1-ODU0 Detection of LSP Regions: – Extend RFC-4206 definition to OTN mux layers ISCD1 < ISCD2 – RFC-4202 (section 2.4.7) to cover differences at two ends of Te-Link Doesn’t work as ISCDs advertised depend on what is switchable on the link (refer to slides #17)

6 What is new Existing mechanisms inadequate – To capture Mux/Dmux information – To detect FA boundaries based on Switching Capabilities The proposal: – Use ISCDs for advertising switching BW per ODU rate – Define a new sub-TLV (under Link TLV) to advertise Mux/Dmux information BW corresponding to root ODU 6

7 The Model Use ISCDs to advertise ODUj (j<=k) Switching BW Use IMCDs to advertise ODUj (j<=k) Termination BW – E.g. BW adv for GPID = ODU4-ODU3-ODU2 corresponds to ODU4 ‘Termination’ IMCD is required for induced FA creation in MLN – includes Single & Multi Stage Multiplexing networks – IMCD advertisement is optional There could be multiple ISCDs and IMCDs advertised per interface – ISCD for each switchable ODUj rate (j<=k) – IMCD for each multi-layered OTN G-PID The IMCD concept can be extended to any multi-layered network

8 Example-1: Advertisement when no FA is required Multiplexing Hierarchy shown is same at both ends of Te-Link Advertise all switchable ODUjs irrespective of the hierarchy (j<=k) If FA is not needed, then IMCD advertisement is NOT required – E.g. - BW adv for red, blue & green links include ISCDs for ODU2, ODU1 & ODU0 as follows 8 ISCDs Adv Main ISCDODUj BW sub TLV in SCSI Max LSP BW (bytes/sec for 8 prio) Available ODUj(s) for 8 prio ISCD1 ODU2 Nominal rate1 ISCD2ODU1 Nominal rate4 ISCD3ODU0 Nominal rate8

9 Example-2: Advertisement to support FA Advertise all switchable ODUjs irrespective of the hierarchy (j<=k ) as before Advertise IMCDs to support FA creation: – IMCD for ODU2 termination at A, B, C & D – IMCD for ODU1 termination at B, C & D Adv by A & B for A-B/B-A Adv by B & C for B-C/C-B Adv by C & D for C-D/D-C 9 IMCDsG-PID Available termination BW for 8 prio IMCD1 ODU2-ODU11 IMCD2ODU2-ODU01 IMCDsG-PID Available termination BW for 8 prio IMCD1 ODU2-ODU11 IMCD2ODU2-ODU01 IMCD3ODU1-ODU04 IMCD4ODU2-ODU1-ODU01 IMCDsG-PID Available termination BW for 8 prio IMCD1 ODU2-ODU11 IMCD2ODU2-ODU1-ODU01 IMCD3ODU1-ODU04 Can be used to create ODU1-FA to switch ODU0s

10 New Sub-TLVs for OTN (G.709–v3)

11 ISCD with new Switching Capability

12 ODUk Switch Capability Specific Information (SCSI)

13 IMCD sub TLV Multiple IMCDs, one per G-PID (mux branch) Applicable to fixed ODUjs only (j <=k) – i.e. parent in any G-PID is always a fixed ODUj Possible to include parent info if required in future in Reserved field The structure is similar to ISCD. We could add technology specific extensions (similar to SCSI in ISCD) if required Can be extended to any multi-layered network

14 Summary & Next Steps ISCDs are sufficient for ODU service creation – Covers VCAT & nxLSP creation ITCD(s) mandatory if inducing FA is necessary Multiple ISCDs, one per ODUj/ODUflex Multiple IMCDs, one per HO-ODUj (J<=k) terminable No correlation among ISCDs No correlation among IMCDs The proposal provides complete solution Would like to take to next level – WG doc IMCD is applicable to any ML network, propose to cover in a separate draft

15 Comments & Response Steve/Xihua: Why IMCD is not present for ODU2-ODU1-ODU0 in example#2 Resp: Should be there. Will include. Fatai: Why do we need IMCD for ODU1-ODU0 Resp: This is required to support FAs at ODU1 layer on OTU2 interface (ref to slide#22 for an e.g.) Lou: Sections 3.x requires cleanup. What should come before how. Resp: Agree, we will clean up this section. Steve: Use of priority in examples: clarify if ‘P’ means only one priority or is it ‘Pi’ Resp: Agree. We will update the examples to show it is ‘Pi’. Curtis: The sub-TLV type and G-PID should be listed as TBD Resp: Agree. We will update the draft.

16 Backup Slides

17 What ISCDs to advertise A-end: – ISCDs : ODU2= 1 – IMCDs ODU2-ODU1=1 ODU1-ODU0 = 4 ODU2-ODU1-ODU0 = 1 B-end: – ISCDs : ODU2= 1 – IMCDs ODU2-ODU0=1 – We can not use ISCDs (RFC 4206 based) to determine ODUj boundaries/LSP regions – We need more than 2 layer relation to support service creation (via FA(s) )

18 Why just 2 layer information is not sufficient: example-1 Node-Y in both cases will advertise these IMCDs: IMCD1: ODU2-ODU1 = 1 IMCD2: ODU1-ODU0 =1 – The above IMCDs doesn’t mean ODU2-ODU1-ODU0 is possible – We need ODU2-ODU1-ODU0 =1 (IMCD3) to support ODU0-LSPs in the first config

19 Why just 2 layer information is not sufficient: example-2 (Bundling dissimilar) Link bundle with dissimilar muxing capabilities: Layer relation In this example, we need two FAs to originate from the same point (at node-B). It is necessary to advertise IMCD3 as we can not conclude full mux relation from IMCD1 & IMCD2. A---------B---------C--------D-------E |------ODU2-FA---| |------ODU1-FA-----------| |----------------ODU0-LSP------------| Link A-B: Hierarchy at both ends is OTU2-ODU2-ODU0 Link B-C: Is a bundled Te-link with 3 component links with multiplexing hierarchy at both ends as shown:

20 Why just 2 layer information is not sufficient: example-2 cont’d (Bundling dissimilar) Component link#1: OTU2 link with mux hierarchy: OTU2-ODU2-ODU1-ODU0 Component link#2: OTU2 link with mux hierarchy: OTU2-ODU2-ODU1 Component link#3: OTU1 link with mux hierarchy: OTU1-ODU1-ODU0 Link C-D: - Hierarchy at C end is OTU2-ODU2 - Hierarchy at D end is OTU2-ODU2-ODU1 Link D-E: - Hierarchy at D end is OTU1-ODU1 - Hierarchy at E end is OTU1-ODU1-ODU0 The IMCDs advertised for B-C would include the following: IMCD1: G-PID = ODU2-ODU1 Available HO-ODUj count at Pi = 2 (ODU2) after LC#1 used up = 1 IMCD2: G-PID = ODU1-ODU0 Available HO-ODUj count at Pi = 5 (ODU1) after LC#1 used up = 1 IMCD3: G-PID = ODU2-ODU1-ODU0 Available HO-ODUj count at Pi = 1 (ODU2) We can’t correlate among IMCD1 & IMCD2 and conclude ODU2-ODU1-ODU0

21 Te-Link with different Switching/Termination Capabilities (why RFC4206 is not adequate) FA-LSP boundary detection: Node-A uses ISCD & Mux-Demux info from B to determine FA boundary/need – Creation of ODU0 client-LSP triggers detection of FA-boundary node(s) ODUj Layer boundary, LSP region (extensions to RFC 4206, section 5.0) – Node-A::ODU0-ISCD < Node-B:: ODU2-ISCD – The above order determines layer boundaries & potential FA boundary nodes – This won’t work as there is no ODU0-ISCD at node-A. ISCD and labels (extensions to RFC 4202, section 2.4) – [ODU0, ODU2] - a link between different ODUj layers – This is on similar lines to [PSC, TDM] relation in RFC 4202 Generalization: – [ODUj, ODUj+1] - a link between different ODUj layers [ODUj, ODUj+1] – label represents ODUj+1 time slots (FA layer label) 21

22 Termination BW for layers other than ODUk Opt#1: ODU3-FA – Locks up bigger pipe between two nodes, in-efficient – scaling issues if P2P ODU3-FAs are used Need a generic solution for FA creation at any HO-ODU layer – Solution should provide a way to create ODU2-FA in this e.g. (see opt#2) – Requires an IMCD with this info ODU2-ODU0 = 4 (ODU2 Termination BW as opposed to ODU0 switching BW

23 New Requirements (What are we trying to address) Focused on building architectural support in the model : 1.To identify FA boundary nodes a)Should cover origination and termination of FAs b)Should cover inducing FA(s) at ODUk layer c)Should cover inducing FA(s) at any HO-ODUj layer(s) (j < k) 2.To identify what ODUj(s) can be extracted after termination of ODUk and/or HO-ODUj layers(s) – Also cover non-OTN cases (e.g. Ethernet over GFP over ODU) 3.To support bundling of links with similar muxing hierarchy 4.To support bundling of links with dissimilar muxing hierarchy 5.Role of LMP in support of the above

24 Mux branch identification: proposed G-PID values New values defined in addition to those defined in RFC 3471 & RFC 4328 Table below shows G-PID combinations for ODU0 within in an ODU4 Value suggested G-PIDThe meaning 60ODU4-ODU0Termination of ODU4 required for ODU0 switching. BW advertised is number of ODU4 terminations possible at the interface 61ODU4-ODU3-ODU0Termination of ODU4 & ODU3 required for ODU0 switching. BW advertised is number of ODU4 terminations possible at the interface 61ODU4-ODU3-ODU2-ODU0Termination of ODU4, ODU3 & ODU2 required. BW advertised is number of ODU4 terminations possible at the interface. 63ODU4-ODU3-ODU2-ODU1-ODU0Termination of ODU4, ODU3, ODU2 & ODU1 required. BW advertised is number of ODU4 terminations possible at the interface ……………………….. 75ODU3-ODU2Termination of ODU3 required. BW advertised is number of ODU3 terminations possible at the interface 76ODU3-ODU0Termination of ODU3 required. BW advertised is number of ODU3 terminations possible at the interface 77ODU2-ODU0Termination of ODU2 required. BW advertised is number of ODU2 terminations possible at the interface 78ODU3-ODU3-ODU0Termination of ODU3 & ODU2 required. BW advertised is number of ODU3 terminations possible at the interface ……………………….. (other G-PID values for ODU1, ODU2, ODU2e, ODUflex, etc)


Download ppt "OSPF-TE extensions for OTN (draft-ashok-ccamp-gmpls-ospf-g709-03) CCAMP IETF-80 (Mar-2011) Rajan Rao Ashok Kunjidhapatham."

Similar presentations


Ads by Google