datatracker.ietf.org
Sign in
Version 5.6.2.p2, 2014-07-24
Report a bug

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

Submission Date: 2007-09-20
From: ITU-T SG 15 (Greg Jones)
To: IETF CCAMP WG (adrian@olddog.co.uk, dbrungard@att.com)
Cc:sob@harvard.edu
dward@cisco.com
rcallon@juniper.net
zinin@psg.com
yoichi.maeda@ntt-at.co.jp
sjtrowbridge@alcatel-lucent.com
hklam@alcatel-lucent.com
betts01@nortel.com
tsbsg15@itu.int
Response Contact: tsbsg15@itu.int
Technical Contact: hklam@alcatel-lucent.com
betts01@nortel.com
Purpose: In response
Attachments: Liaison Statement to CCAMP on Multi-Layer Network I-Ds - body text
Body:
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:
ftp://ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html>