datatracker.ietf.org
Sign in
Version 5.4.0, 2014-04-22
Report a bug

Liaison Statement: Liaison Reply to IETF PCE WG on Application of PCE to Inter-Layer Networks

Submission Date: 2008-02-29
From: ITU-T SG 15 (Greg Jones)
To: IETF PCE WG (jpv@cisco.com, adrian@olddog.co.uk)
Cc:sob@harvard.edu
rcallon@juniper.net
dward@cisco.com
pce@ietf.org
yoichi.maeda@ntt-at.co.jp
sjtrowbridge@alcatel-lucent.com
Response Contact: tsbsg15@itu.int
Technical Contact: betts01@nortel.com
hklam@alcatel-lucent.com
Purpose: For information
Attachments: LS220 - body text in pdf
Body:
Thank you for bring the PCE drafts to our attention.  There has been
recent work in SG15 on layer architecture and control plane discussion
on interlayer aspects.
A recent Recommendation G.800 “Unified Functional Architecture of
Transport Networks” describes the architecture of transport networks
that encompasses G.805, which is applicable to connection-oriented
technologies, and G.809, which is applicable to connectionless
technologies.  All three Recommendations use the term “layer” which
refers to the generation, transport and termination of a particular
type of information (or “characteristic information”).  While the use
of the term has identical meaning in many cases between SG15 documents
and the PCE drafts, reading the I-Ds with the G.800 definition of layer
suggests that clarification of the terms “higher layer” and “lower
layer” would be helpful.  We assume that this is the same as the
client-server relationship in G.800.  One implication of this is that a
lower (server) layer does not necessarily imply that the characteristic
information transferred is larger (more bits) than the higher (client)
layer.  Examples of this would be an inverse mux layer (e.g., a VCAT
layer such as VC-3-3v) to its constituent layer, or a packet in packet
case.  Another implication is that the technology of the higher and
lower layer could even be the same (packet in packet).

Regarding draft-ietf-pce-inter-layer-frwk-05.txt, Q12/15 has been
discussing topology representations for multi-layer networks and two
models have emerged.  The first represents a layer network with
resources strictly in that layer.  If server layers can be used to
connect portions of the layer network of interest, then this can be
represented as a link or node, sometime called pseudo links or pseudo
nodes.  This appears to be similar to the representation of the dotted
link in the various figures of the I-D.
PCEs can have visibility of individual layers with the potential
connectivity.  Multiple layer visibility would be accomplished by
putting several layers into scope of one PCE.
Another representation of the topology is one in which links from all
layers are in the graph and adaptations supported at each link end are
represented.  Path computations on this model would be allowed to
follow pairs of adaptations that exist on links such that the ingress
and egress layers end up being the same.  Pruning of the graph prior
to, or during, the path calculation by removing links whose
ingress/egress layers are not desired, can improve the efficiency of
the calculation.
Restricting PCE visibility to one or subset of the available layers of
this second model is needed for the multiple PCE inter-layer path
computation of section 3.2.  It could be done with some type of VNT
manager.

Comments by section on draft-ietf-pce-inter-layer-req-06.txt are:
1. Introduction.  Current text (in paragraph 3) suggests that the
optimization is required.  We suggest that the requirement be phrased
as “It is important to be able to optimize network resource utilization
globally…” since there may be non-technical reasons that prevent global
optimization.  Similarly, it is suggested that some brief discussion of
resource ownership be included as administrative/ownership boundaries
between layers can affect the ability to optimize.  For example, if a
server layer only uses the management plane for connection
establishment (no control plane).
2. Section 3.1.2. It should be clarified that when a PCC makes a
request, it should specify the layer for which it is requesting a path.
 If there are several “mono” layers that could satisfy a path request,
what indication is given to the PCE about which to select?
3. Section 3.1.3.  It may be helpful to have a depth indicator in the
original PCC request that limits the maximum number of adaptations
allowed in the returned path.  Similarly some indicator of how many
administrative boundaries to cross could be useful to contain the cost
of a potential path.
An electronic copy of this liaison statement is available at:
ftp://ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html