[CCAMP] upstream label and label symmetry

Ramon Casellas <ramon.casellas@cttc.es> Fri, 08 November 2013 02:32 UTC

Return-Path: <ramon.casellas@cttc.es>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4BD21E814B for <ccamp@ietfa.amsl.com>; Thu, 7 Nov 2013 18:32:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ERxIeuFX35J for <ccamp@ietfa.amsl.com>; Thu, 7 Nov 2013 18:32:48 -0800 (PST)
Received: from villa.puc.rediris.es (villa.puc.rediris.es [IPv6:2001:720:418:ca00::7]) by ietfa.amsl.com (Postfix) with ESMTP id 8829D21E8119 for <ccamp@ietf.org>; Thu, 7 Nov 2013 18:32:48 -0800 (PST)
Received: from [84.88.62.208] (helo=leo) by villa.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <ramon.casellas@cttc.es>) id 1VebsM-0002Im-EA for ccamp@ietf.org; Fri, 08 Nov 2013 03:32:46 +0100
Received: from [31.133.165.128] (dhcp-a580.meeting.ietf.org [31.133.165.128]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 573501FD41 for <ccamp@ietf.org>; Fri, 8 Nov 2013 03:32:44 +0100 (CET)
X-Envelope-From: ramon.casellas@cttc.es
Message-ID: <527C4D4A.8040404@cttc.es>
Date: Fri, 08 Nov 2013 03:32:42 +0100
From: Ramon Casellas <ramon.casellas@cttc.es>
Organization: CTTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "ccamp@ietf.org" <ccamp@ietf.org>
Content-Type: multipart/alternative; boundary="------------040309080406070705040205"
X-Spamina-Bogosity: Ham
Subject: [CCAMP] upstream label and label symmetry
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Nov 2013 02:32:50 -0000

All,

If I may, just my 2 cents, and trying to summarize the main raised 
points. For people working on GMPLS for optical networks it is a common 
requirement.

* Use case: for example, transparent WSON, it is required to fulfil the 
wavelength continuity constraint (WCC); likewise, although the optical 
receiver/photodetector may be broadband it is a common requirement that 
both labels (that are contiguous due to the WCC) are the same 
(symmetry). Someone put it better than me [2] including our soon to be 
ex-secretary:

 > 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.





* IMHO it is true that a node needs to cross-connect before forwarding 
the PATH message downtream: RFC3473
"3.1. Procedures

    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,(...)

    An intermediate node must also allocate a label on the outgoing
    interface and establish internal data paths before filling in an
    outgoing upstream label and propagating the Path message

* The fact that the label is set to some value 0xFFF...FF and that the 
node must cross-connect justifies the need for a two step process as 
Dieter mentioned.


In short, IMHO there is a requirement to request symmetrical labels.  
This problem has been mentioned in the past, you may want to check

[1] http://tools.ietf.org/html/draft-oki-ccamp-upstream-labelset-00

[2] draft-xu-rsvpte-bidir-wave-00.txt
      see http://permalink.gmane.org/gmane.ietf.ccamp/6023

Thanks

Ramon