Skip to main content

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

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2008-02-29
From Group ITU-T-SG-15
From Contact Hiroshi Ota
To Group pce
To Contacts 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