1 / 11

ASON routing implementation and testing ASON routing extensions

This draft discusses the testing experience and extensions for ASON routing, specifically the OIF bandwidth advertisement and ISCD extensions.

johnajones
Download Presentation

ASON routing implementation and testing ASON routing extensions

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. ASON routing implementation and testing ASON routing extensions IETF 76 – Hiroshima – Nov‘09 L. Ong (Ciena) lyong@ciena.com

  2. Draft on ASON Routing Testing Experience • CCAMP work on ASON Routing is Experimental • No standard codepoints have been allocated • OIF has experimented with similar extensions • Transport-only instance of OSPF (no IP routing) • Advertising reachable local address prefixes • Advertising local/remote TE router IDs for scoping of routing information (Li/Pi mapping) • Details in draft-ong-gmpls-ason-routing-exper-00.txt • OIF would like to see this work on Standards Track • Contribution provides input on testing of similar extensions • Tested at interops since 2003, most recently 2007 & 2009 • At least 7 independent implementations each time • OIF extensions are offered for CCAMP use • Can these extensions be adopted directly? “Running code” • Will experience help to move work to Standards Track?

  3. OIF Bandwidth advertisement extension • OIF ISCD extension: • Combines advertisement of bandwidth for multiple signal types in one ISCD • Advertises separate availability per signal type • Why • Standard signal types are placed along specific boundaries • Availability for new connections at STS-3c/VC-4 or STS-12c/VC-4-4 depends on position of occupied timeslots • Cannot be determined from total unreserved bytes per second • Combination is more efficient than separate ISCD or LSA per signal type • Most link attributes are common across signal types, combining reduces duplication • Although these are “layers” in ITU-T sense, they share the same switching matrix STS-12c STS-3c STS-1

  4. Draft on Extended Routing Functions • Follow up on previous liaison providing requested detail: • Layer-scoped Link Attributes • Layer = VC-3, VC-4 • Connections available at a particular layer • Attributes (e.g., metric) that differ for a layer • Local Connection Type • CP or TCP (switch or terminate) • Within layer, not multilayer/adaptation-related • Looking for better solution than ISCD/IACD • NSAP format Local Node Prefix • In addition to IPv4 and IPv6 formats • New draft submitted with more detail • draft-theillaud-gmpls-ason-routing-add-fcts-01.txt

  5. Layer-scoped link attributes • G.7715.1 specifies a set of link characteristics specific to a particular layer network • Most of these attributes would be common across layer networks supported by a particular link • However, OIF members believe that some attributes may take different values for different TDM layers, esp: • Link available bandwidth • TE metric • Possibly others such as administrative group • Therefore, the ability to support advertisement of common attributes on a per link basis but also to allow some attributes to be scoped to a layer would be highly useful

  6. Layer-scoped link attributes potential solutions • Advertising multiple TE LSAs for a given link, the LSA itself scoping the attributes • Is this allowed by GMPLS protocol? • Is this an efficient mechanism? • New sub-TLV allowing to scope some attributes to a specific layer • Proposed in the draft, see draft for details

  7. Link associated local connection type • Section 4.1 in draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt proposes to rely on the ISCD(s) advertised by each link endpoints, to infer the link local connection type • Inferring the local connection type from ISCDs is not sufficient • See example • An explicit local connection type parameter is desirable • detailed proposed extension contained in the draft

  8. Backup

  9. Link Characteristics

  10. Link associated local connection type • For this link, both nodes would advertise the same ISCD for the VC-3 layer. Node 1 would in addition advertise an ICSD for the VC-4 layer. • A path computation entity would believe that a HO VC-3 connection can be set up across this link, while it cannot • Node2 “terminates” both HO VC-4 and HO VC-3 layers • Node2 can switch a LO VC-3 layer (from a terminated HO VC-4 signal) Node1 Node2 • Switching functions • LO VC-3 • Switching functions • HO VC-4 • HO VC-3

  11. Thanks to contributors • Richard Graveman (Department of Defense) • Hans-Martin Foisel (Deutsche Telekom) • Thierry Marcot (France Telecom) • Evelyne Roch (Nortel Networks) • Jonathan Sadler (Tellabs) • Yoshiaki Sone (NTT Corporation) • Takehiro Tsuritani (KDDI R&D Laboratories) • Xihua Fu (ZTE)

More Related