Liaison statement
Liaison Statement to CCAMP on Multi-Layer Network I-Ds

State Posted
Posted Date 2007-09-20
From Group ITU-T-SG-15
From Contact Greg Jones
To Group ccamp
To Contacts
Response Contact
Technical Contact
Purpose In response
Attachments Liaison Statement to CCAMP on Multi-Layer Network I-Ds - body text
Your liaison response regarding our comments on multi-layer networks was
discussed in the joint Q12 and Q14 of SG15 meeting and we appreciate very much
the accommodation shown to us by delaying the last calls so that it could be
considered at our meeting.  There is ongoing work in SG15 on interlayer aspects
of ASON and this opportunity to comment on the MLN drafts is thus timely. •  
  Usage of the term “adaptation� We have just realized that the ITU-T
G.805-based interpretation of the term “adaptation� may differ from the
interpretation and usage of the term “adaptation� within the draft (e.g.
the discussion in Section 3.2.2 of <draft-ietf-ccamp-gmpls-mln-eval-03.txt>).
It would be helpful to include a definition of adaptation as used by the draft,
and possibly a note that identifies the difference to avoid terminology
misinterpretation. For future work, we suggest examining the implications of
G.805 adaptations. Some further comments and suggestions are provided below
related to the usage of G.805 adaptation in advertisements: With respect to
draft-ietf-ccamp-gmpls-mln-reqs-05.txt, we suggest that adaptation capability
per link be advertised.  This is more general than switching capability as
switching capability can be inferred from adaptation. When G.805 adaptation is
used, adaptation capabilities could be represented using encodings so that
layer relationships can be processed by path computation functions without
having to know the semantics of the layer.  In this manner, when a layer is
added in the future, existing path computation functions can use it.  To
accomplish this, the adaptation encoding would also need to express the
quantity of client information (i.e. number of timeslots, or bandwidth) that
can be carried by a server layer trail or a specified number of server trails
in case inverse multiplexing is applied. For illustrative purposes, an example
of such an encoding approach follows: This encoding could be done as follows: 
Layers and adaptation methods are treated as enumerated types.  Specific
adaptations supported are then advertised as a tuple consisting of <client
layer type value, server layer type value, adaptation method type value, client
layer quantity, server layer quantity>.  The path computation function then
uses this information to identify paths that utilize pairs of adaptations
(client-to-server followed by server-to-client) along with server layer
connections to satisfy an end-to-end connection request. •     Multi-layer
topology construct With respect to the view of the multi-layer topology
construct, we would like to offer the following observation regarding the
general problem of utilizing multiple layers to satisfy a connection request at
a given layer can be solved by several methods, and that two methods are
describe in the draft.  The first method exposes adaptations between layers
that are permitted to be used by advertising them in a single multi-layer
topology.  The second method uses a virtual link construct entirely in a client
layer to represent potential server layer connectivity.  This approach
constructs separate topologies per layer.  We note that a virtual node
construct could also be part of solutions to the problem. An electronic copy of
this liaison statement is available at:>