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
•	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
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:>