One document matched: draft-otani-ccamp-gmpls-cspf-constraints-04.txt
Differences from draft-otani-ccamp-gmpls-cspf-constraints-03.txt
IETF Internet Draft Tomohiro Otani
Proposed status: Standards Track Kenichi Ogaki
Expires: April 2007 KDDI R&D Labs
Arthi Ayyangar
Kireeti Kompella
Juniper Networks
Rajiv Papneja
Isocore
October 2006
GMPLS constraints consideration for CSPF path computation
Document: draft-otani-ccamp-gmpls-cspf-constraints-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
This draft provides the guideline to consider generalized multi-
protocol label switching (GMPLS) traffic-engineering (TE) attributes
for constraint-based shortest path first (CSPF) path computation at a
source node in a GMPLS network environment. This draft summarizes
most possible cases of GMPLS constraint TE attributes at an ingress
link, transit links and an egress link to establish a GMPLS label
switched path (LSP) appropriately.
T. Otani et al. Expires April 2007 1
Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-04.txt
October 2006
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1. Introduction....................................................3
2. Conventions used in this document...............................3
3. Assumed network model...........................................3
4. CSPF consideration..............................................5
5. Security consideration.........................................12
6. Intellectual property considerations...........................12
7. Informative references.........................................13
Author's Addresses................................................13
Document expiration...............................................14
Copyright statement...............................................14
T. Otani et al. Expires 2006 2
Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-04.txt
October 2006
1. Introduction
A GMPLS network is, in general, controlled and managed by various
GMPLS specific TE attributes underlying used physical/logical
technologies of links as well as nodes [Arch]. To establish a GMPLS
LSP appropriately in such a networking environment, these TE
attributes (advertised from others or belonging to themselves) must
be dealt correctly when CSPF path computation under a certain GMPLS
constraint is conducted [GMPLS-routing], and GMPLS LSP must be
created following a feasible route. However, since these constraints
vary and are differently understood among such an integrated
environment (especially between optical transport point of view and
packet transport point of view), this draft proposes and provides a
kind of guideline to facilitate GMPLS CSPF path computation,
summarizing most possible cases of GMPLS constraint attributes at an
ingress link, transit links and an egress link to establish a GMPLS
LSP appropriately.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
3. Assumed network model
3.1 GMPLS TE attributes consideration for CSPF calculation
For CSPF path computation to establish GMPLS LSPs correctly, various
GMPLS attributes [GMPLS-routing, GMPLS-OSPF] of links as well as
nodes, as indicated below, must be taken into account in a GMPLS
network environment in addition to TE attributes of packet based
network [OSPF-TE].
(1) Encoding-type: SONET/SDH, Lambda, Ethernet, etc.
(2) Switching capability: TDM, Lambda, Fiber, etc.
(3) Bandwidth: OC-192, OC-48, GbE, 10GbE, etc.
These logical attributes have a very tight relationship with
underlying physical technologies such as SONET/SDH, optical transport
network (OTN) or Ethernet in terms of links, and all-optical switches,
SONET/SDH-basis digital cross connect or electrical-basis optical
switches in terms of nodes. Therefore, the GMPLS LSPs must satisfy
logical constrains as well as corresponding physical constraints.
These constraints are sometimes differently understood among
different layers, and a logically computed GMPLS LSP may violate the
physical constraints, therefore, a consistent guideline to solve this
issue should be formulated.
T. Otani et al. Expires 2006 3
Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-04.txt
October 2006
3.2 Considered network model
Figure 1 depicts a typical GMPLS network, consisting of an ingress
link, a transit link as well as an egress link, to investigate a
consistent guideline for GMPLS CSPF path computation. Each link
outgoing or incoming at each interface has its own switching
capability, encoding-type and bandwidth.
The consideration here is based on a single domain GMPLS network, but
the analysis may be able to be applicable to an inter-domain GMPLS
network.
Ingress Transit Egress
+-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+
|Node1|------------>|Node2|------------>|Node3|------------>|Node4|
| |<------------| |<------------| |<------------| |
+-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+
Figure 1: GMPLS network model
For the simplicity of the analysis in CSPF consideration, the below
basic assumptions are made when the LSP is created.
(1) Switching capabilities (SC) of outgoing links from the
ingress and egress nodes (link1-2 and link4-3 in Figure 1)
must be consistent with each other.
(2) SC of all transit links including incoming links to the
ingress and egress nodes (link2-1 and link3-4) should be
consistent with switching type of a LSP to be created.
(3) Encoding-types of all transit links should be consistent
with encoding type of a LSP to be created.
GMPLS network is a multi-layer network, which is composed of multiple
nodes with different switching capability and encoding type
interfaces. Therefore, a hierarchical structure may be considered in
CSPF path computation. In such a case, the combination between the
switching type and encoding type of a desired LSP, and those of all
transit links described as the table in following section may be
acceptable. One of advertised multiple interface switching capability
descriptors for the same link [GMPLS-Routing] should be also
appropriately chosen as the attribute for the link.
Bandwidth of each TE link is maximum LSP bandwidth in interface
switching capability descriptor at the priority for a desired LSP
[GMPLS-OSPF], and encoding-types of incoming and outgoing links on
the same interface (for example, link1-2 and link2-1) should be
consistent with each other.
T. Otani et al. Expires 2006 4
Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-04.txt
October 2006
In case that the network is comprised of numbered links and
unnumbered links [RFC3477], an ingress node, who is able to support
numbered links and unnumbered links may choose both links being part
of the same desired LSP.
4. CSPF consideration
In this section, we consider GMPLS constraints to be satisfied in
different cases of link attributes. When a LSP indicated in below
tables is created, the CSPF path computation must choose the route so
as to satisfy switching capability, encoding-type and bandwidth at
the ingress link, transiting links and the egress link indicated in
columns next to the created LSP, considering underlying physical
constraints. Here, almost cases of GMPLS CSPF consideration are
summarized in this document, however, some cases will be added in a
future version.
(1) TDM-switch capable
Table 1: Desired GMPLS attributes in the case of TDM-SC
+-------------+---------+------------+---------+------------------+
|LSP attribute|Ingress |Transit |Egress |Remarks |
+---+---------+---------+------------+---------+------------------+
| | |TDM | |TDM | |
| | +---------+ +---------+ |
|SC*|TDM |L2SC |TDM |L2SC | |
| | +---------+ +---------+ |
| | |PSC | |PSC | |
+---+---------+---------+------------+---------+ |
| |SONET/SDH|SONET/SDH|SONET/SDH |SONET/SDH|Specified in G.691|
| +---------+---------+------------+---------+ |
|Enc|Ethernet |Ethernet |SONET/SDH |Ethernet |Specified in IEEE |
| | | |or Ethernet | | |
| +---------+---------+------------+---------+ |
| |OTN* |OTN |OTN |OTN | |
+---+---------+---------+------------+---------+ |
|BW |X |<=bw |<=bw |<=bw | |
+---+---------+---------+------------+---------+------------------+
*SC in LSP means a desired switching type of LSP.
*OTN interfaces are equivalent to digital wrapper technology in this
draft.
In this case, since the interface with TDM SC supports sub-rate
switching, BW X can be equal to or less than bw of ingress, transit
and egress links, and must be larger than the minimum LSP bandwidth
T. Otani et al. Expires 2006 5
Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-04.txt
October 2006
in the interface switching capability descriptor. A sub-rate
switching is unsuited for a hierarchical LSP, because the lower-layer
link usually has larger granular bandwidth than that layer except
PSC-x, for example a TDM LSP with the desired bandwidth of OC-12
should not use a lambda switching capable link with the bandwidth of
OC-48 as a transit link. In such a case, a lambda LSP as a forwarding
adjacency (FA) LSP is created on the lower (lambda) layer in advance,
then the FA-LSP [LSP-HIER] may be advertised as a TDM SC link.
(2) Lambda switch capable (LSC)
Table 2.1: The case of end-point(Ingress/Egress) link attributes
without lambda encoding
+-------------+---------+------------+---------+------------------+
|LSP attribute|Ingress |Transit |Egress |Remarks |
+---+---------+---------+------------+---------+------------------+
| | |LSC | |LSC | |
| | +---------+ +---------+ |
|SC |LSC |TDM |LSC |TDM | |
| | +---------+ +---------+ |
| | |L2SC | |L2SC | |
| | +---------+ +---------+ |
| | |PSC | |PSC | |
+---+---------+---------+------------+---------+[GMPLS-Routing] |
| |SONET/SDH|SONET/SDH|SONET/SDH |SONET/SDH|section 3.6, 3.9 |
| | | |or lambda | |Specified in G.691|
| +---------+---------+------------+---------+ |
|Enc|Ethernet |Ethernet |Ethernet |Ethernet |Specified in IEEE |
| | | |or lambda | | |
| +---------+---------+------------+---------+ |
| |OTN |OTN |OTN |OTN |Specified in G.709|
| | | |or lambda | | |
|---+---------+---------+------------+---------+ |
|BW |X |=bw |=bw |=bw | |
| | | |or *<=bw | | |
+---+---------+---------+------------+---------+------------------+
If an interface supports only a specific bit-rate and format such as
SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to
match bit-rate and its framing.
*In the case of an interface with a lambda encoding and a transparent
to bit-rate and frameing, BW X must be equal to or less than bw.
T. Otani et al. Expires 2006 6
Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-04.txt
October 2006
Table 2.2: The case of end-point(Ingress/Egress) link attributes
with lambda encoding
+-------------+---------+------------+---------+------------------+
|LSP attribute|Ingress |Transit |Egress |Remarks |
+---+---------+---------+------------+---------+------------------+
| | |LSC | |LSC | |
| | +---------+ +---------+ |
|SC |LSC |TDM |LSC |TDM | |
| | +---------+ +---------+ |
| | |L2SC | |L2SC | |
| | +---------+ +---------+ |
| | |PSC | |PSC | |
+---+---------+---------+------------+---------+ |
| |lambda | |lambda | |[GMPLS-Routing] |
| +---------+ +------------+ |section 3.7, 3.10 |
|Enc|SONET/SDH| |SONET/SDH | |Specified in G.691|
| | | |or lambda | | |
| +---------+lambda +------------+lambda | |
| |Ethernet | |Ethernet | |Specified in IEEE |
| | | |or lambda | | |
| +---------+ +------------+ | |
| |OTN | |OTN | |Specified in G.709|
| | | |or lambda | | |
+---+---------+---------+------------+---------+ |
|BW |X |<=bw |=bw |<=bw | |
| | | |or *<=bw | | |
+---+---------+---------+------------+---------+------------------+
If an interface supports only a specific bit-rate and format such as
SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to
match bit-rate and its framing.
*In the case of an interface with a lambda encoding and a transparent
to bit-rate and frameing, BW X must be equal to or less than bw.
T. Otani et al. Expires 2006 7
Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-04.txt
October 2006
Table 2.3: The case of one end-point (Ingress/Egress) link
attribute with lambda encoding
+-------------+---------+------------+---------+------------------+
|LSP attribute|Ingress |Transit |Egress |Remarks |
+---+---------+---------+------------+---------+------------------+
| | |LSC | |LSC | |
| | +---------+ +---------+ |
|SC |LSC |TDM |LSC |TDM | |
| | +---------+ +---------+ |
| | |L2SC | |L2SC | |
| | +---------+ +---------+ |
| | |PSC | |PSC | |
+---+---------+---------+------------+---------+[GMPLS-Routing] |
| |SONET/SDH| |SONET/SDH |SONET/SDH|section 3.6, 3.9 |
| | | |or lambda | |Specified in G.691|
| +---------+ +------------+---------+ |
|Enc|Ethernet |lambda |Ethernet |Ethernet |Specified in IEEE |
| | | |or lambda | | |
| +---------+ +------------+---------+ |
| |OTN | |OTN |OTN |Specified in G.709|
| | | |or lambda | | |
+---+---------+---------+------------+---------+ |
|BW |X |<=bw |=bw |=bw | |
| | | |or *<=bw | | |
+---+---------+---------+------------+---------+------------------+
The case of ingress link with the specific encoding and egress link
with lambda encoding also follows the same manner.
If an interface supports only a specific bit-rate and format such as
SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to
match bit-rate and its framing.
*In the case of an interface with a lambda encoding and a transparent
to bit-rate and frameing, BW X must be equal to or less than bw.
T. Otani et al. Expires 2006 8
Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-04.txt
October 2006
(3) Fiber switch capable (FSC)
Table 3.1: The case of end-point(Ingress/Egress) link attributes
without lambda or fiber encoding
+---+---------+---------+------------+---------+------------------+
|LSP attribute|Ingress |Transit |Egress |Remarks |
+---+---------+---------+------------+---------+------------------+
| | |FSC | |FSC | |
| | +---------+ +---------+ |
| | |LSC | |LSC | |
| | +---------+ +---------+ |
|SC |FSC |TDM |FSC |TDM | |
| | +---------+ +---------+ |
| | |L2SC | |L2SC | |
| | +---------+ +---------+ |
| | |PSC | |PSC | |
+---+---------+---------+------------+---------+[GMPLS-Routing] |
|Enc|SONET/SDH|SONET/SDH|SONET/SDH |SONET/SDH|section 3.6, 3.9 |
| | | |or lambda | |Specified in G.691|
| | | |or fiber | | |
| +---------+---------+------------+---------+ |
| |Ethernet |Ethernet |Ethernet |Ethernet |Specified in IEEE |
| | | |or lambda | | |
| | | |or fiber | | |
| +---------+---------+------------+---------+ |
| |OTN |OTN |OTN |OTN |Specified in G.709|
| | | |or lambda | | |
| | | |or fiber | | |
+---+---------+---------+------------+---------+ |
|BW |X |=bw |=bw |=bw | |
| | | |or *<=bw | | |
+---+---------+---------+------------+---------+------------------+
If an interface supports only a specific bit-rate and format such as
SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to
match bit-rate and its framing.
*In the case of an interface with a lambda or fiber encoding and a
transparent to bit-rate and frameing, BW X must be equal to or less
than bw.
T. Otani et al. Expires 2006 9
Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-04.txt
October 2006
Table 3.2: The case of end-point(Ingress/Egress) link attributes with
lambda or fiber encoding
+---+---------+---------+------------+---------+------------------+
|LSP attribute|Ingress |Transit |Egress |Remarks |
+---+---------+---------+------------+---------+------------------+
| | |FSC | |FSC | |
| | +---------+ +---------+ |
| | |LSC | |LSC | |
| | +---------+ +---------+ |
|SC |FSC |TDM |FSC |TDM | |
| | +---------+ +---------+ |
| | |L2SC | |L2SC | |
| | +---------+ +---------+ |
| | |PSC | |PSC | |
+---+---------+---------+------------+---------+[GMPLS-Routing] |
| |fiber |fiber |fiber |fiber |section 3.8 |
| +---------+---------+------------+---------+ |
|Enc|lambda | |lambda | |section 3.7, 3.10 |
| | | |or fiber | | |
| +---------+ +------------+ |section 3.6, 3.9 |
| |SONET/SDH| |SONET/SDH | |Specified in G.691|
| | | |or lambda | | |
| | |lambda |or fiber |lambda | |
| +---------+or fiber +------------+or fiber | |
| |Ethernet | |Ethernet | |Specified in IEEE |
| | | |or lambda | | |
| | | |or fiber | | |
| +---------+ +------------+ | |
| |OTN | |OTN | |Specified in G.709|
| | | |or lambda | | |
| | | |or fiber | | |
+---+---------+---------+------------+---------+ |
|BW |X |<=bw |=bw |<=bw | |
| | | |or *<=bw | | |
+---+---------+---------+------------+---------+------------------+
If an interface supports only a specific bit-rate and format such as
SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to
match bit-rate and its framing.
*In the case of an interface with a lambda or fiber encoding and a
transparent to bit-rate and frameing, BW X must be equal to or less
than bw.
T. Otani et al. Expires 2006 10
Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-04.txt
October 2006
Table 3.3: The case of one end-point (Ingress/Egress) link attribute
with lambda or fiber encoding
+---+---------+---------+------------+---------+------------------+
|LSP attribute|Ingress |Transit |Egress |Remarks |
+---+---------+---------+------------+---------+------------------+
| | |FSC | |FSC | |
| | +---------+ +---------+ |
| | |LSC | |LSC | |
| | +---------+ +---------+ |
|SC |FSC |TDM |FSC |TDM | |
| | +---------+ +---------+ |
| | |L2SC | |L2SC | |
| | +---------+ +---------+ |
| | |PSC | |PSC | |
+---+---------+---------+------------+---------+[GMPLS-Routing] |
|Enc|SONET/SDH| |SONET/SDH |SONET/SDH|section 3.6, 3.9 |
| | | |or lambda | |Specified in G.691|
| | | |or fiber | | |
| +---------+ +------------+---------+ |
| |Ethernet |lambda |Ethernet |Ethernet |Specified in IEEE |
| | |or fiber |or lambda | | |
| | | |or fiber | | |
| +---------+ +------------+---------+ |
| |OTN | |OTN |OTN |Specified in G.709|
| | | |or lambda | | |
| | | |or fiber | | |
+---+---------+---------+------------+---------+ |
|BW |X |<=bw |=bw |=bw | |
| | | |or *<=bw | | |
+---+---------+---------+------------+---------+------------------+
The case of ingress link with the specific encoding and egress link
with lambda encoding also follows as the same manner.
If an interface supports only a specific bit-rate and format such as
SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to
match bit-rate and its framing.
*In the case of an interface with a lambda encoding and a transparent
to bit-rate and frameing, BW X must be equal to or less than bw.
Although the interface with FSC can switch the entire contents to
another interface, this interface should be used for only optical
wavelength or waveband switching.
T. Otani et al. Expires 2006 11
Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-04.txt
October 2006
(4) Layer 2 switch capable (L2SC)
The guideline for the calculation must be created after the
definition and discussion about L2SW are settled down.
(5) Packet switch capable (PSC)
Table 4: Desired GMPLS attributes in the case of PSC
+-------------+---------+------------+---------+------------------+
|LSP attribute|Ingress |Transit |Egress |Remarks |
+---+---------+---------+------------+---------+------------------+
|SC |PSC |PSC |PSC |PSC | |
+---+---------+---------+------------+---------+ |
|Enc|Packet |Packet |Packet |Packet | |
+---+---------+---------+------------+---------+ |
|BW |X |<=bw |<=bw |<=bw | |
+---+---------+---------+------------+---------+------------------+
Since the interface with PSC supports only packet-by-packet switching,
BW X must be equal to or less than bw, and must be larger than the
minimum LSP bandwidth.
These GMPLS constraints must be considered for computing CSPF and
creating GMPLS LSPs.
6. Security consideration
GMPLS CSPF consideration will not change the underlying security
issues.
7. Intellectual property considerations
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
T. Otani et al. Expires 2006 12
Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-04.txt
October 2006
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
8. Informative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Arch] E. Mannie, "Generalized Multi-Protocol Label
Switching Architecture", RFC3945, October, 2004.
[GMPLS-Routing] K. Kompella and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label
Switching", RFC4202, October 2005.
[GMPLS-OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in
Support of Generalized Multi-Protocol Label
Switching", RFC4203, October 2005.
[OSPF-TE] Katz, D., et al, "Traffic Engineering (TE) Extensions
to OSPF Version 2", RFC3630, September 2003.
[RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumberd
Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)", RFC3477, January 2003.
[LSP-HIER] K.Komepella and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC4204,
October 2005.
Author's Addresses
Tomohiro Otani
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino-shi
Saitama, 356-8502 Japan
Phone: +81-49-278-7357
Email: otani@kddilabs.jp
Kenichi Ogaki
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino-shi
Saitama, 356-8502 Japan
Phone: +81-49-278-7897
Email: ogaki@kddilabs.jp
Arthi Ayyangar
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089 US
Email: arthi@juniper.net
T. Otani et al. Expires 2006 13
Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-04.txt
October 2006
Rajiv Papneja
Isocore
12359 Sunrise Valley Drive
Suite 100, Reston, VA 20191 US
Email: rpapneja@isocore.com
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089 US
Email: kireeti@juniper.net
Document expiration
This document will be expired in April 2007, unless it is updated.
Copyright statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
T. Otani et al. Expires 2006 14
| PAFTECH AB 2003-2026 | 2026-04-23 11:33:47 |