Return-Path: 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 7E7961B2BE3 for ; Mon, 23 Jun 2014 11:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Jt51Av2nLrVC for ; Mon, 23 Jun 2014 11:12:04 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0641B2BEC for ; Mon, 23 Jun 2014 11:11:52 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5NIBfZ6029930; Mon, 23 Jun 2014 19:11:41 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5NIBdFr029891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jun 2014 19:11:40 +0100 From: "Adrian Farrel" To: "'Varma, Eve L \(Eve\)'" , References: <00fd01cf8a2b$6bbd2b20$43378160$@olddog.co.uk> <018b01cf8ee2$86dfca00$949f5e00$@olddog.co.uk> <6D32668528F93D449A073F45707153D82C453F91@US70UWXCHMBA03.zam.alcatel-lucent.com> In-Reply-To: <6D32668528F93D449A073F45707153D82C453F91@US70UWXCHMBA03.zam.alcatel-lucent.com> Date: Mon, 23 Jun 2014 19:11:38 +0100 Message-ID: <006f01cf8f0e$94212cf0$bc6386d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0070_01CF8F16.F5F35090" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKBuc+ah7SVDmb5y4DTHoRqwLQAxAFLdRM6AXtdMG0BOrCI85n6nSEg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20776.000 X-TM-AS-Result: No--21.768-10.0-31-10 X-imss-scan-details: No--21.768-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFqnykMun0J1wvhavVZP5tTaWNQzVV5GESlzdsYu/rQxIted muI9uycY1aznZlwqFDyaWO9OagVe2WC+RjBytve09IHCgeTQv1Pb4SkGdkTN9fWAXs8IQX1uEjs PbT+bo3LSyV59bDpyKomln5gZaJr1yUEGXxYlhT/aGKmW8Fvr+5UJWEPHy1YzmKASVRjLg93OEM terKmLMa4E78t0Np88+CxaXbqeVYNtJNTxpengRjNKWYiz0CE6AHN/Ezu9EnHoN8DSoota+Q6T3 3ZkaHAH+22OskOP/18KJdewsLHkJE3zbqyumWRbqeBupNgLgYf4uJ1REX4MHfViWe8qsIm3fdVw Vn9D963yrR8SjRpKInX895AHigUCh0zWQXCZZ8iJQ9k+Ypk5CWip/IHMbRnmJDftO4aKCRsWSxD 9c23vtWdWKq3yWZFSn8wrgJJ0KIuveTp3UjBuIJRrnSy7UTtbzJHaSc2zFBEM74Nf6tTB9gdtTM LT3zSbtFtXLwAwPQqKKmBfzcRfFu4dcT3ZaToc4t2mucDkRBFIn9CXeywIecJX6c73jkGLgjuzl /ha28004qbhupdmyNACeWZ6/YSZ9bQi0x27p1Xzh2yKdnl7WDRsfGqPls+VLLHGkgXj4A8evlPw WFA5dUASEP17SfpVK/tJNHjRjDwUR2ITUggE0y4uTw19Klh6m/y00tE9StbzYcyIF7RSVYeW7KS +lMd2uP6Ui3HidxC+lzz13XWUhKuThJWNM5Sq4vPWjjRvIip5y+Nu7/EOOkMQ2BHsYzyTD/xWx/ Q7rZ0pdqELfwOQWpYlxuk1ogQA+zoAW8R15l+eAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7GqSJe3/DJB6IAcCikR3vq+/ELQi3wGARxXZVH8D8X9hfXgJbkxYl9znKreCQTKT7img/fEE WTsv Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/_TEmalIsDD73wu4gahGxGBYeI8E 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 18:12:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0070_01CF8F16.F5F35090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ah, Eve, thanks. Inverse mux is a useful term. You can inverse mux over a set of channels that may or may not be contiguous. Adrian From: Varma, Eve L (Eve) [mailto:eve.varma@alcatel-lucent.com] Sent: 23 June 2014 14:21 To: adrian@olddog.co.uk; malcolm.betts@zte.com.cn Cc: ccamp@ietf.org Subject: RE: [CCAMP] Adding composite labels to flexi-grid Hi Adrian, I think the intended point is that since each network media channel has an effective frequency slot with a nominal central frequency and slot width, while you might think of making a wider slot as allocating extra increments (e.g., 12.5GHz or 50GHz at a time), it is still one slot with a greater width. But since this is talking about the channel and not the signal, this isn't concatenation, it is just wider effective frequency slots for the channel (and non-contiguous network media channels are simply different network media channels). As Malcolm indicated below, if the intention is, for example, to support carrying a B100G signal over multiple different (non-contiguous) network media channels, that would be inverse muxing vs. concatenation. Best regards, Eve From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, June 23, 2014 8:56 AM To: malcolm.betts@zte.com.cn Cc: ccamp@ietf.org Subject: Re: [CCAMP] Adding composite labels to flexi-grid 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" Sent by: "CCAMP" 17/06/2014 08:55 AM Please respond to adrian@olddog.co.uk To , 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 -------------------------------------------------------- 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. ------=_NextPart_000_0070_01CF8F16.F5F35090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ah, Eve, = thanks.

 

Inverse mux is a useful term. = You can inverse mux over a set of channels that may or may not be = contiguous.

 

Adrian

 

From: Varma, Eve L = (Eve) [mailto:eve.varma@alcatel-lucent.com]
Sent: 23 June = 2014 14:21
To: adrian@olddog.co.uk; = malcolm.betts@zte.com.cn
Cc: ccamp@ietf.org
Subject: = RE: [CCAMP] Adding composite labels to = flexi-grid

 

Hi Adrian,

 

I think the intended point is that since each = network media channel has an effective frequency slot with a nominal = central frequency and slot width, while you might think of making a = wider slot as allocating extra increments (e.g., 12.5GHz or 50GHz at a = time), it is still one slot with a greater width. But since this is = talking about the channel and not the signal, this isn’t = concatenation, it is just wider effective frequency slots for the = channel (and non-contiguous network media channels are simply different = network media channels).

 

As Malcolm indicated below, if the intention is, = for example, to support carrying a B100G signal over multiple different = (non-contiguous) network media channels, that would be inverse muxing = vs. concatenation.

 

Best regards,

Eve

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of = Adrian Farrel
Sent: Monday, June 23, 2014 8:56 = AM
To: malcolm.betts@zte.com.cn
Cc: = ccamp@ietf.org
Subject: Re: [CCAMP] Adding composite labels to = flexi-grid

 

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<= /a>]
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

=3D=3D=3D= =3D

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.

=3D=3D=3D

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

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

 

------=_NextPart_000_0070_01CF8F16.F5F35090--