[CCAMP] Adding composite labels to flexi-grid

["Adrian Farrel" <[e-mail]>]

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.