[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new draft about signaling for a bidirectionl lightpath
Hi, Diego
I think that every way you said enables a bidirectional lambda LSP
although every has different aspect (no extension, signaling ext.,
routing ext., and computation).
No. 2 is a signaling extension. Without upstream label set, our
proposal works well because each intermediate node selects only
lambdas that are available in both directions. However, with upstream
label set (i.e., more extension), the applicability is expanded.
Anyway, I also feel the lambda switching is becoming interesting again
after available lambda-related components are increased.
Best regards,
- Hiroaki
From: "Diego Caviglia (GA/ERI)" <diego.caviglia@ericsson.com>
Subject: RE: new draft about signaling for a bidirectionl lightpath
Date: Tue, 10 Jul 2007 08:52:17 +0200
Message-ID: <0428AC48A879ED46A94F39D5665DF6848E6D11@esealmw110.eemea.ericsson.se>
> Hi Hiroaki,
> I think that this is a real problem that can be addressed in several way:
>
> 1 Label set and Upstream label + crankback: this should works but of course is not optimal;
> 2 The way you proposed with Upstream label set;
> 3 A modification to the routing protocol in order to advertise the available lambdas;
> 4 A centralized PCE approach adding manually (or via modified routing protocols) the lambda availability
>
> The above should covers the lambda continuity problem but not the optical impairments one.
>
> Seems that after some years of sleeping the Lambda switching is becoming interesting again there are several drafts on this topic.
>
> Best regards
>
> Diego
>
>
> -----Original Message-----
> From: Hiroaki Harai [mailto:harai@nict.go.jp]
> Sent: sabato 7 luglio 2007 4.01
> To: Diego Caviglia (GA/ERI); ccamp@ops.ietf.org
> Subject: Re: new draft about signaling for a bidirectionl lightpath
>
> Hi, Diego.
>
> I think the usage that you mentioned (using label set and upstream
> label) is not enough by the following two reasons.
>
> 1. [Non-support of multiple lambdas] Upstream label object conveys
> only ONE label, which is likely to face lack of the same lambda as
> that in the previous link. We have high blocking probability for
> LSP setup. If we convey multiple lambdas for upstream, the
> probability would be reduced significantly (but, we cannot convey).
>
> Someone may want to change lambda in Upstream Label into other
> lambda among lambdas in the Label Set when the lambda in Upstream
> Label is not acceptable further. However, according to Section 3.1
> of RFC 3473, if label in Upstream Label is not acceptable, PathErr
> is generated. Different from Suggested Label, we have no chance to
> change. So, using Upstream Label is not enough.
>
> =========================
> 3.1 Procedures (RFC 3473)
> The process of establishing a bidirectional LSP follows the
> establishment of a unidirectional LSP with some additions. To
> support bidirectional LSPs an Upstream_Label object is added to the
> Path message. The Upstream_Label object MUST indicate a label that
> is valid for forwarding at the time the Path message is sent.
> When a Path message containing an Upstream_Label object is
> received, the receiver first verifies that the upstream label is
> acceptable. If the label is not acceptable, the receiver MUST issue
> a PathErr message with a "Routing problem/Unacceptable label value"
> indication. The generated PathErr message MAY include an Acceptable
> Label Set, see Section 4.1.
> =========================
>
> 2. [Keep flexibility] The same lambda on both directions may not
> reqested for some bidirectional LSPs different from the case in
> this draft. In this case, once we pose the same lambda constraint
> against upstream label, we lose flexiblity to setup LSPs by
> different lambda in each direction.
>
> Best regards,
> - Hiroaki
>
>
>
> From: "Diego Caviglia (GA/ERI)" <diego.caviglia@ericsson.com>
> Subject: RE: new draft about signaling for a bidirectionl lightpath
> Date: Fri, 6 Jul 2007 15:00:13 +0200
> Message-ID: <0428AC48A879ED46A94F39D5665DF6848BE088@esealmw110.eemea.ericsson.se>
>
> >
> > Hi Hiroaki,
> > Not clear to me why the mechanism using label set with the same lambda as the Upstream label is not enough here.
> >
> > BR
> >
> > Diego
> >
> >
> >
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Hiroaki Harai
> > Sent: venerdì 6 luglio 2007 3.10
> > To: ccamp@ops.ietf.org
> > Subject: new draft about signaling for a bidirectionl lightpath
> >
> > Hi everyone,
> >
> > We posted a new draft about GMPLS signaling for a bidirectional
> > lightpath setup as follows.
> > http://www.ietf.org/internet-drafts/draft-xu-rsvpte-bidir-wave-00.txt
> >
> > ======
> > Title : Extensions to GMPLS RSVP-TE for Bidirectional Lightpath with
> > the Same Wavelength
> > Authors : S. Xu, H. Harai, and D. King
> > Filename: draft-xu-rsvpte-bidir-wave-00.txt
> >
> > Abstract: For bidirectional lightpaths provisioning, in the case of
> > optical nodes that do not support wavelength conversion, it would be
> > necessary to use the same wavelength along the route on each
> > direction. In certain optical network scenarios, the use of the same
> > wavelength on both directions would be advantageous. For instance,
> > some type of ROADMs may add/drop the same wavelength
> > simultaneously. In another case, the users' optical end nodes are
> > equipped with fixed-wavelength transponders.
> >
> > This document describes extensions to RSVP-TE signaling for
> > bidirectional wavelength lightpaths that require the same wavelength on
> > both directions. By using an LSP_ATTRIBUTES object defined in [RFC4420],
> > the extensions enable the new type lightpaths to support the low cost
> > configuration at users' optical end nodes.
> > ======
> >
> > We believe that selecting a single wavelength on both directions for a
> > bidirectional LSP is very real. And our suggestion in this draft is a
> > simple one.
> >
> > We appreciate your comments and feedbacks.
> >
> > With best regards,
> > Hiroaki
> >
> > -------
> > Hiroaki Harai, Ph.D. (http://nag.nict.go.jp/)
> > Network Architecture Group, New Generation Network Research Center
> > National Institute of Information and Communications Technology (NICT), JAPAN.
> > Email: harai@nict.go.jp; Phone: +81-42-327-5418; FAX: +81-42-327-6680
> >
> >
>