INTERNET-DRAFT Tomohiro Otani (Editor) Intended Status: Informational Kenichi Ogaki (Editor) Expires: September 2007 KDDI R&D Labs Daniel King (Editor) Aria Networks March 2007 Considering Generalized Multiprotocol Label Switching Traffic Engineering Attributes During Path Computation Document: draft-otani-ccamp-gmpls-cspf-constraints-05.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 IETF Trust (2007). All Rights Reserved. Abstract This document provides guidelines for the consideration of Generalized Multiprotocol Label Switching (GMPLS) Traffic- Engineering (TE) attributes for computation of routes for Label Switched Paths (LSPs) in a GMPLS network. This document summarizes how GMPLS TE attributes on ingress links, transit links, and egress links may be treated as path computation constraints to determine the route of a GMPLS Label Switched Path. T. Otani et al. Expires September 2007 [Page 1] draft-otani-ccamp-gmpls-cspf-constraints-05.txt March 2007 Table of Contents 1. Introduction.................................................... 2 2. Assumed Network Model........................................... 3 2.1 GMPLS TE Attributes Consideration for Path Calculation ....... 3 2.2 Considered Network Model...................................... 3 3. Path Computation Considerations................................. 4 3.1. TDM-Switch Capable........................................... 5 3.2. Lambda Switch Capable (LSC).................................. 6 3.3. Fiber Switch Capable (FSC)................................... 9 3.4. Layer 2 Switch Capable (L2SC)............................... 12 3.5. Packet Switch Capable (PSC)................................. 12 4. Security Consideration......................................... 12 5. IANA Considerations............................................ 13 6. Acknowledgements............................................... 13 7. Intellectual Property Considerations........................... 13 8. References..................................................... 13 8.1 Normative References......................................... 13 8.2 Informative References....................................... 14 Terminology 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 [RFC2119]. 1. Introduction A network is, in general, controlled and managed taking into account various attributes of the underlying technologies of the physical and logical links and nodes. In a network operated using Generalized Multiprotocol Label Switching (GMPLS) protocols, many of these Traffic Engineering (TE) attributes are advertised using routing protocols [RFC3945], [RFC4202]. To establish a GMPLS Label Switched Path (LSP) it is necessary to compute a route or path for that LSP either hop-by-hop or by the pre-calculation of part or all of the path. In order that the route selected is capable of satisfying the requirements of the user or application that will use the LSP the computation must be constrained by a set of LSP-specific requirements and the TE attributes advertised within the network. Further, considerations of technology and node or link capabilities may also provide restrictions to the feasibility of LSP establishment on certain routes, and this can be deduced from the TE attributes advertised within the network and used by the path computation algorithms to select only viable routes. In a mixed, integrated network (for example, one containing optical switches and packet routers) these constraints may vary and are understood differently for different equipment and different LSPs. T. Otani et al. Expires September 2007 [Page 2] draft-otani-ccamp-gmpls-cspf-constraints-05.txt March 2007 This document provides guidelines to facilitate path computation for GMPLS LSPs by summarizing how GMPLS TE attributes on ingress links, transit links, and egress links may be treated as path computation constraints to determine the route of a GMPLS Label Switched Path. 2. Assumed Network Model 2.1 GMPLS TE Attributes Consideration for Path Calculation For path computation to establish GMPLS LSPs correctly, various GMPLS attributes [RFC4202], [RFC4203] 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 [RFC3630]. (1) Encoding-type: Synchronous Optical Network(SONET)/Synchronous Digital Hierarchy (SDH), Lambda, Ethernet, etc. (2) Switching capability: Time Division Multiplex (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. 2.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 path computation. Each link 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 maybe applicable to an inter-domain GMPLS networks. Ingress Transit Egress +-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+ |Node1|------------>|Node2|------------>|Node3|------------>|Node4| | |<------------| |<------------| |<------------| | +-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+ Figure 1: GMPLS Network Model T. Otani et al. Expires September 2007 [Page 3] draft-otani-ccamp-gmpls-cspf-constraints-05.txt March 2007 For the simplicity of the analysis in path 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. A GMPLS network maybe a multi-layer network, which is composed of multiple nodes with different switching capabilities and interface encoding types. Therefore, a hierarchical structure may be considered in 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 [RFC4202] 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 [RFC4203], 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. 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. 3. Path Computation Considerations 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 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 path computation consideration are summarized in this document, however, some cases will be added in a future version. T. Otani et al. Expires September 2007 [Page 4] draft-otani-ccamp-gmpls-cspf-constraints-05.txt March 2007 3.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 document. * BW is the desired bandwidth of the LSP * bw is the bandwidth available on the link 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 in the interface switching capability descriptor. 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 is created in the lower (lambda) layer in advance, and may be advertised as a TDM TE link. T. Otani et al. Expires September 2007 [Page 5] draft-otani-ccamp-gmpls-cspf-constraints-05.txt March 2007 3.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 | | +---+---------+---------+------------+---------+[RFC4202] | | |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 framing, BW X must be equal to or less than bw. T. Otani et al. Expires September 2007 [Page 6] draft-otani-ccamp-gmpls-cspf-constraints-05.txt March 2007 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 | |[RFC4202] | | +---------+ +------------+ |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 framing, BW X must be equal to or less than bw. T. Otani et al. Expires September 2007 [Page 7] draft-otani-ccamp-gmpls-cspf-constraints-05.txt March 2007 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 | | +---+---------+---------+------------+---------+[RFC4202] | | |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 framing, BW X must be equal to or less than bw. T. Otani et al. Expires September 2007 [Page 8] draft-otani-ccamp-gmpls-cspf-constraints-05.txt March 2007 3.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 | | +---+---------+---------+------------+---------+[RFC4202] | |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 framing, BW X must be equal to or less than bw. T. Otani et al. Expires September 2007 [Page 9] draft-otani-ccamp-gmpls-cspf-constraints-05.txt March 2007 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 | | +---+---------+---------+------------+---------+[RFC4202] | | |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 framing, BW X must be equal to or less than bw. T. Otani et al. Expires September 2007 [Page 10] draft-otani-ccamp-gmpls-cspf-constraints-05.txt March 2007 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 | | +---+---------+---------+------------+---------+[RFC4202] | |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 framing, 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 only be used for optical wavelength or waveband switching. T. Otani et al. Expires September 2007 [Page 11] draft-otani-ccamp-gmpls-cspf-constraints-05.txt March 2007 3.4. Layer 2 Switch Capable (L2SC) The guideline for the calculation must be created after the definition and discussion about L2SW are settled down. 3.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 paths and creating GMPLS LSPs. This document does not discuss domain based multilayer path computation considerations where specific routing policies, which are sometimes independent from the underlying domains and sometimes take the underlying domains' policies into consideration, are required. 4. Security Consideration Anything that can be done to change the output of a path computation algorithm can significantly affect the operational stability of a network, could force traffic to traverse undesirable or costly links, and could place data into less secure parts of the network. Therefore, the integrity of the path computation mechanism is very significant in a GMPLS network. The path computation algorithm, itself, and the mechanisms for conveying computed paths to and between the LSRs in the network are out of scope for this document. But misuse or confusion with respect of the handling of the attributes described in this document could leave a network open to various security attacks. In particular, if there is a known mismatch between the interpretation or handling of TE attributes within a network this might be exploited by an attacker to cause disruption or to waste network resources in an integrated multi-technology network. Therefore, network operators are RECOMMENDED to use a consistent approach across the whole network. T. Otani et al. Expires September 2007 [Page 12] draft-otani-ccamp-gmpls-cspf-constraints-05.txt March 2007 5. IANA Considerations This informational document makes no requests for IANA action. 6. Acknowledgements Thanks to Adrian Farrel for his review of this document. 7. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 8. References 8.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4202] Kompella, K., and Rekhter, Y., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", RFC4202, October 2005. [RFC4203] Kompella, K., and Rekhter, Y., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching", RFC4203, October 2005. T. Otani et al. Expires September 2007 [Page 13] draft-otani-ccamp-gmpls-cspf-constraints-05.txt March 2007 8.2 Informative References [RFC3477] Kompella, K., and Rekhter, Y., "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC3477, January 2003. [RFC3630] Katz, D., et al., "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC3630, September 2003. [RFC3945] Mannie, E., et al., "Generalized Multi-Protocol Label Switching Architecture", RFC3945, October, 2004. Authors' 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 Nuova Systems 2600 San Tomas Expressway Santa Clara, CA 95051 Email: arthi@nuovasystems.com 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 Daniel King Aria Networks Ltd. Email: daniel.king@aria-networks.com T. Otani et al. Expires September 2007 [Page 14] draft-otani-ccamp-gmpls-cspf-constraints-05.txt March 2007 Document Expiration This document will be expired in September 2007, unless it is updated. Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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 September 2007 [Page 15]