1. IETF-69th Chicago1 Extensions to GMPLS RSVP-TE for Bidirectional Lightpath with the Same Wavelength draft-xu-rsvpte-bidir-wave-00 Sugang Xu, Hiroaki Harai, Daniel King xsg@nict.go.jpxsg@nict.go.jp, harai@nict.go.jp, daniel.king@aria-networks.comharai@nict.go.jpdaniel.king@aria-networks.com

2. IETF-69th Chicago2 Special optical network scenarios for bidirectional lightpath provisioning –Only specific wavelength can be used –Some types of ROADM need to add/drop wavelength simultaneously –Wavelength continuity constraint –Fixed wavelength multiplexers/demultiplexers like AWGs –Fixed tuned wavelength transponders different wavelengthsSolution of port-remapping problem of bidirectional lightpath with different wavelengths using fix-tuned wavelength media converter (MC) Lack port-remapping flexibility With flexibility by OXC Cost efficiency of reusing the wavelengths in either direction, considering it has a significant sparing cost benefits Support for Bidirectional Lightpath with the Same Wavelength on Both Directions Would Be Advantageous MC GE Optical End Node Core Node MC GE Optical End Node Core Node

3. IETF-69th Chicago3 Some Possible Approaches Two unidirectional lightpaths in converse directions with the same wavelength (A1) –Sequentially verify the same wavelength availability in both directions and crankback if failure. –Need wavelength available information, may take time for crankback in wavelength scanning process Label set and Upstream label + crankback (A2) –Specify wavelength on both directions –Need wavelength available information, may suffer from a high blocking probability and time-consuming for crankback process Label set and Upstream Label set (A3) –Add constraint in wavelength available information updating process on both directions in Label set and Upstream Label set –Upstream Label set has not been standardized yet

4. IETF-69th Chicago4 Label Set Object and Bidirectional Lightpath (Prop) Using LSP_ATTRIBUTES Object –To trigger the new functionality at each GMPLS node –LSP_ATTRIBUTES object and related mechanism meet the requirement of new control functionalities [RFC4420] –One bit in Attributes Flags TLV indicates the new type lightpath Label set updateSmall block extensions to signaling in procedure for Label set update ONLY Label set –Upstream-and-Downstream common free wavelengths information updating at each node and carried by Label set Joint –Upstream-and-Downstream OXC Joint configurations

5. IETF-69th Chicago5 Reduced Messaging and a Lower Blocking Probability 1 round message exchanging a b c Path Msg Resv Meg Path Msg Resv Meg Avg. round # of messaging until success and blocking probability (W=32) Single wavelength occupation rate/link W W: Number of wavelengths H H: Number of Hops A1 A1: Uni Setups A2 A2: With UpLabel A3 A3: With UpLabel set Prop Prop: With Label set R R: Avg. number of rounds P b P b : Blocking probability

6. IETF-69th Chicago6 Issues in Protocol Extensions under Consideration Performance improvement –Provide a low blocking probability –Provide reduced message exchange –With a low latency of provisioning Independent of the precise wavelength availability information –Assume that no precise wavelength availability information can be guaranteed or even available before signaling –Inherit the idea of wavelength verification using Label set Small block of extension –A new refined unit function as that for unidirectional lightpath provisioning –Interact with other protocols as LITTLE as possible, for example, it may involve extensions in signaling only, or may also require extensions in other protocols outside the signaling –If it is possible to resolve the problem within the signaling, it is required to involve objects as LITTLE as possible

7. IETF-69th Chicago7 Summary and Next Action Proposal Support for bidirectional lightpath with the same wavelength on both directions would be cost effective. The draft was recently announced to the mailing list and we have already received initial feedback. The authors would like to continue work on the draft and identify areas that need to be added and improved. The authors plan to poll optical network operators and vendors to request feedback. The authors then plan to include suggestions from the WG, Operators and Vendors and then issue a new version of the draft.