1 / 24

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

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 )

dylan
Download Presentation

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

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

More Related