Liaison statement
Liaison Statement to CCAMP on Multi-Layer Network I-Ds
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2007-09-20 |
From Group | ITU-T-SG-15 |
From Contact | Hiroshi Ota |
To Group | ccamp |
To Contacts | 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> |