OSPF-TE extensions for OTN (draft-ashok-ccamp-gmpls-ospf-g709-03)

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

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 • Moved away from single ISCD to multiple ISCDs • One ISCD per ODU rate (as discussed in Beijing) • Identified new requirements • Muxing restrictions & service creation • Induced FAs & OTN multiplexing hierarchy • Consistency with RFC6001 • 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

4. Path computation – what is required 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

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

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

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 : • To identify FA boundary nodes • Should cover origination and termination of FAs • Should cover inducing FA(s) at ODUk layer • Should cover inducing FA(s) at any HO-ODUj layer(s) (j < k) • 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) • To support bundling of links with similar muxing hierarchy • To support bundling of links with dissimilar muxing hierarchy • 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