Re: [CCAMP] Adding composite labels to flexi-grid

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 23 June 2014 12:56 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADECE1B2AA3 for <ccamp@ietfa.amsl.com>; Mon, 23 Jun 2014 05:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.199
X-Spam-Level:
X-Spam-Status: No, score=-99.199 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a42clIjrfAzQ for <ccamp@ietfa.amsl.com>; Mon, 23 Jun 2014 05:56:25 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10DCA1B2937 for <ccamp@ietf.org>; Mon, 23 Jun 2014 05:56:23 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5NCuLGI012469; Mon, 23 Jun 2014 13:56:21 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5NCuJOL012460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jun 2014 13:56:20 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: malcolm.betts@zte.com.cn
References: <00fd01cf8a2b$6bbd2b20$43378160$@olddog.co.uk> <OF9E67B067.34FB5D5C-ON85257CFC.0035F006-85257CFC.0037F299@zte.com.cn>
In-Reply-To: <OF9E67B067.34FB5D5C-ON85257CFC.0035F006-85257CFC.0037F299@zte.com.cn>
Date: Mon, 23 Jun 2014 13:56:18 +0100
Message-ID: <018b01cf8ee2$86dfca00$949f5e00$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_018C_01CF8EEA.E8A89ED0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKBuc+ah7SVDmb5y4DTHoRqwLQAxAFLdRM6mg/wy7A=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20774.006
X-TM-AS-Result: No--19.213-10.0-31-10
X-imss-scan-details: No--19.213-10.0-31-10
X-TMASE-MatchedRID: IeZYkn8zfFqnykMun0J1wkhEDfw/93Buy3fMd7pCml6NXkYeZoSa+v80 kikrnFDpWCXgPKIt5M6WZJl0b7VT9bmvMSppeWbN/O70vD0Lt8COCCRo/fBZSU+0uGVOF08QXkh fj9Xlxy0sU2D8r2q8NKldHs0DobMiMqritzVgGxbRc75iroKqArtq3FNsoMQgng4VduaO4WlrQg SRg6yiRSbi7begRHJeJvUu96TaLgfTrbBiEFSMvI+YSzwl92XTUCwb19dUaUlDrg3+Z9OuMteCU pQERi3J8SXQ3wH4DTtuPDPlj1XJQO7Dh9vlQ65VVF7yOiu4q2lB+8LAeeOOMEmDyxNPdHMX152a 4j27JxjVrOdmXCoUPElBc2Is9ewqr3k6d1IwbiCUa50su1E7W8yR2knNsxQRDO+DX+rUwfaICe2 qFQ5BFLpH7YnohyPyfdTAWJ8WVbuJxJdlNqfJF7MjW/sniEQKRyLSVzNLnaxfpVdfidExN+RJLX Fn/M4bU9Bu+efCJtD5X613LZxaNGS5WQj/NRvE5lxBdzMDWW5imi8LvNfmr6nu3/KtWfGQLyc54 RnMqireXk2Sjuhu0ETfQWhBnwHOeY8gy0Lhxg+9HTxRE6QQB6KaxHqGRwkCowtRP8whCK9Yua/k yrSLK+/8FpDFWSowI/HesLke34cNzkh8+BAiiH9NanCUA4VedWAGleXmdhhiOMENWKv3dNqE+67 0/uY7nLfqYaQ5cxgopAQlzvHAhyzhss0AlBiqnVTWWiNp+v9BldmDYjwlppuSv4SfxhK3AEoaRb 3OefkwvxENl9ez41zoSSbt5EWXVMjaUlx6hKeeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7GqSJe3/DJB6IAcCikR3vq8Vg0FnmvRSZiDJxsrSwkFVdvFcIpxG9jcjX3zWopJ7DRp6GRfC 7J0y
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/CfI7vdkr8vD_SSOC3wZsPktrWcQ
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Adding composite labels to flexi-grid
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Mon, 23 Jun 2014 12:56:29 -0000

Hi Malcolm,
 
Thanks for this.
 
In terms of over-extended analogies, maybe there is a tendency to over-extend
the meaning of the term/concept VCAT.
 
I disagree that the result of adjacent concatenated media channels is a larger
media channel. There is a distinction between building a larger (if you like,
wider) channel either simply through a larger value of m or through the
so-called "super channel", and constructing a set of media channels as you
describe it.
 
You say "The concept of VCAT only applies to digital streams, it cannot be
applied to the media layer layer" and i think this is taking the architecture
too far into the implementation. But also that this is not an important part of
the discussion.
 
So, to take your analogy, the sender of water has a big tank with a flow that
goes here to there. The "composite label" describes a set of parallel pipes. How
the water is distributed across those pipes is not in scope for this document.
 
I think we can address your concerns by renaming Section 2.1 to "Composite
Labels" and tweaking the text. Thus...
 
2.1.  Composite Labels
 
   It is possible to construct an end-to-end connection by
   "concatenating" more than one flexi-grid slot.  The mechanism used in
   GMPLS is similar to that used to support virtual concatenation (VCAT)
   familiar in time-division multiplexing (TDM) and optical transport
   networks (OTN).  The concatenated slots could potentially be 
   contiguous or non-contiguous (as allowed by the definitions of the
   data plane) and could be signaled as a single LSP or constructed from
   a group of LSPs.  For more details, refer to Section 4.3.
 
This specifically does not say that the "concatenated" construction is VCAT. And
it states that the similarity is in GMPLS. Furthermore, it delegates the
applicability to the definition of the data plane.
 
Similarly, Section 4.3 can be renamed "Composite Labels". The only other change
in that Section I believe is needed to address your concerns is to remove
mention of VCG from the final paragraph. Thus:
 
   Note further that while the mechanism described here naturally means
   that all component channels are corouted, a composite channel can
   also be achieved by constructing individual LSPs from single flexi-
   grid slots and managing those LSPs as a group.  A mechanism for 
   achieving this for TDM is described in [RFC6344], but is out of scope
   for discussion in this document because the labels used are normal,
   single slot labels and require no additional definitions.
 
Cheers,
Adrian
 
From: malcolm.betts@zte.com.cn [mailto:malcolm.betts@zte.com.cn] 
Sent: 19 June 2014 11:11
To: adrian@olddog.co.uk
Cc: ccamp@ietf.org; CCAMP
Subject: Re: [CCAMP] Adding composite labels to flexi-grid
 
Hi Adrian, 

I have some concerns about using the term VCAT in the context of a media
channel. The media is flat and has no structure so if the "concatenated" media
channels are adjacent, we have a larger media channel. If (as I think you
intend) the media channels are not adjacent then you have a set of media
channels. 

Another way of looking at this (and please don't over extend the analogy) is
water and pipe. The water is the optical signal and the media channel is the
pipe. This draft is addressing the management of pipes. 

The concept of VCAT only applies to digital streams, it cannot be applied to the
media layer layer. 

This concept of a group (or set) of media channels may be useful in the future
after SG15 have completed the work on OTN B100G where the possibility of inverse
multiplexing a 400G OTN digital stream into two (or four) digital streams which
are then modulated onto two (or four) optical signals that use two (or four)
independent media channels is under consideration and managing these independent
media channels as a set would be useful. However, this is still under discussion
in SG15. 

Regards, 

Malcolm 




"Adrian Farrel" <adrian@olddog.co.uk> 
Sent by: "CCAMP" <ccamp-bounces@ietf.org> 
17/06/2014 08:55 AM 

Please respond to
adrian@olddog.co.uk

To
<ccamp@ietf.org>, 

cc
	

Subject
[CCAMP] Adding composite labels to flexi-grid
 
		



Hi,

Ramon and I have worked up some text to go in
draft-ietf-ccamp-flexigrid-lambda-label to describe composite labels.

There is not a huge amount to say *in*this*document* partly because we have lots
of running code about how to do VCAT in a number of technologies, and partly
because this document describes the label format, not the signaling, routing, or
usage.

Would like your comments and plan to post before the Toronto cut-off. We can
return to the debate in Toronto if it needs f2f time.

BTW, as an aside, this is deliberately not intended to discuss the "super
channel". At this stage, super-channel is not something that the ITU-T
recognises as a data plane concept (although I know a number of companies are
interested in this and will work in that area). Iftekhar has a strong interest
in describing GMPLS labels and processing for super channels, and has indicated
that he is willing to be an anchor for this work in the IETF.

Thanks,
Adrian

====

New section

2.1.  Virtual Concatenation

  It is possible to construct an end-to-end connection by
  "concatenating" more than one flexi-grid slot.  The mechanism used is
  similar to virtual concatenation (VCAT) familiar in time-division
  multiplexing (TDM) and optical transport networks (OTN).  The
  concatenated slots could potentially be contiguous or non-contiguous
  (as allowed by the definitions of the data plane) and could be
  signaled as a single LSP or constructed from a group of LSPs.  For
  more details, refer to Section 4.3.

===

New section

4.3.  Virtual Concatenation

  Virtual concatenation is already supported in GMPLS for TDM and OTN
  [RFC4606], [RFC6344], [RFC7139].  The mechanism used for flexigrid is
  similar.

  To signal an LSP that uses multiple flexi-grid slots a "compound
  label" is constructed.  That is, the LABEL object is constructed from
  a concatenation of the 64-bit Flexi-Grid Labels shown in Figure 1.
  The number of elements in the label can be determined from the length
  of the LABEL object.  The resulting LABEL object is shown in Figure
  2 including the object header that is not normally shown in
  diagrammatic representations of RSVP-TE objects.  Note that r is the
  count of component labels, and this is backward compatible with the
  label shown in Figure 1 where the value of r is 1.

  The order of component labels MUST be presented in increasing order
  of the value n.  Implementations MUST NOT infer anything about the
  encoding of a signal into the set of slots represented by a compound
  label from the label itself.  Information about the encoding MAY be
  handled in other fields in signaling messages or through an out of
  band system, but such considerations are out of the scope of this
  document.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Object Length (4 + 8r)      | Class-Num (16)|  C-Type (2)   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Grid | C.S.  |    Identifier   |              n                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              m                |          Reserved             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                                                               ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Grid | C.S.  |    Identifier   |              n                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              m                |          Reserved             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 2 : A Compound Label for Virtual Concatenation

  Note that specific rules must be applied as follows:

  - Grid MUST show "ITU-T Flex" value 3 in each component label.
  - C.S. MUST have the same value in each component label.
  - Identifier in each component label may identify different physical
    equipment.
  - Values of n and m in each component label define the slots that
    are concatenated.

  At the time of writing [G.694.1] only supports the concatenation of
  adjacent slots (i.e., without intervening unused slots that could be
  used for other purposes) of identical width (same value of m), and
  the component slots must be in increasing order of frequency (i.e.,
  increasing order of the value n).  The mechanism defined here MUST 
  NOT be used for other forms of concatenation unless and until those
  forms of concatenation are defined and documented in Recommendations
  published by the ITU-T.

  Note further that while the mechanism described here naturally means
  that all component channels are corouted, a composite channel can
  also be achieved by constructing individual LSPs from single flexi-
  grid slots and managing those LSPs as a Virtual Concatenation Group
  (VCG).  A mechanism for achieving this for TDM is described in
  [RFC6344], but is out of scope for discussion in this document
  because the labels used are normal, single slot labels and require no
  additional definitions.

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
 <https://www.ietf.org/mailman/listinfo/ccamp>
https://www.ietf.org/mailman/listinfo/ccamp


 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any
attachment transmitted herewith) is privileged and confidential and is intended
for the exclusive use of the addressee(s).  If you are not an intended
recipient, any disclosure, reproduction, distribution or other dissemination or
use of the information contained is strictly prohibited.  If you have received
this mail in error, please delete it and notify us immediately.