[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: new draft about signaling for a bidirectionl lightpath
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
>
>