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 |