Presentation is loading. Please wait.

Presentation is loading. Please wait.

ASON routing implementation and testing ASON routing extensions IETF 76 – Hiroshima – Nov‘09 L. Ong (Ciena)

Similar presentations


Presentation on theme: "ASON routing implementation and testing ASON routing extensions IETF 76 – Hiroshima – Nov‘09 L. Ong (Ciena)"— 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-1 STS-3c STS-12c

4 Draft on Extended Routing Functions Follow up on previous liaison providing requested detail: 1.Layer-scoped Link Attributes Layer = VC-3, VC-4 Connections available at a particular layer Attributes (e.g., metric) that differ for a layer 2.Local Connection Type CP or TCP (switch or terminate) Within layer, not multilayer/adaptation-related –Looking for better solution than ISCD/IACD 3.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 Link CharacteristicChanges per TDM Signal Notes Link IDN Link EndpointsN Link Protection TypeN SRLG InformationN Interface Switching CapabilityNSwType=TDM EncType=SDH Administrative GroupPDetermined by policy TE MetricPDetermined by policy BandwidthYAvailable bw differs per signal type

10 Link associated local connection type Switching functions 1.HO VC-4 2.HO VC-3 Switching functions 1.LO VC-3 Node1 Node2 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)

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)


Download ppt "ASON routing implementation and testing ASON routing extensions IETF 76 – Hiroshima – Nov‘09 L. Ong (Ciena)"

Similar presentations


Ads by Google