IETF Internet Draft Tomohiro Otani Proposed status: Best Current Practice Kenichi Ogaki Expires: Aug. 2005 KDDI R&D Labs Arthi Ayyangar Juniper Networks February 2005 GMPLS constraints consideration for CSPF path computation Document: draft-otani-ccamp-gmpls-cspf-constraints-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. "This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This draft provides the guideline to consider generalized multi- protocol label switching (GMPLS) traffic-engineering (TE) attributes for constraint-based shortest path first (CSFP) 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 node, transiting nodes and an egress node to establish a GMPLS label switched path (LSP) appropriately. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 T. Otani et al. Informational - Expires January 2005 1 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February 2005 1. Introduction....................................................3 2. Conventions used in this document...............................3 3. Assumed network model...........................................3 4. CSPF consideration..............................................4 5. Security consideration..........................................7 6. Intellectual property considerations............................7 7. Informative references..........................................7 Author's Addresses.................................................7 Document expiration................................................8 Copyright statement................................................8 T. Otani et al. Informational - Expires January 2005 2 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February 2005 1. Introduction A GMPLS network is, in general, controlled and managed by various GMPLS specific TE attributes underlying used physical/logical technologies of nodes as well as links [Arch]. To establish a GMPLS LSP appropriately in such a networking environment, these TE attributes (advertised from others or belonging to themselves) must be deal with correctly when CSPF path computation under a certain GMPLS constraint is conducted [GMPLS-routing], and GMPLS LSP must be created following an appropriate route. However, since these attributes varies and are differently understood among such an industrial 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 CSFP path computation, summarizing most possible cases of GMPLS constraint attributes at an ingress node, transiting nodes and an egress node 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 nodes as well as TE links, as indicated below, must be took 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 created GMPLS LSPs must satisfy logical constrains as well as corresponding physical constraints. These constraints are sometimes differently understood among industries, and a logically computed GMPLS LSP may violate the physical constraints, therefore, the consistent guideline to solve this issue should be formulated. T. Otani et al. Informational - Expires January 2005 3 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February 2005 3.2 Considered network model Figure 1 depicts a typical GMPLS network, consisting of an ingress node, transiting nodes as well as an egress node, to investigate a consistent guideline for GMPLS CSPF path computation. Each node has its own switching capability of sc^in, sc^tr, or sc^eg, and each TE link generating or terminating at each node has its own encoding-type of enc^in, enc^tr or enc^eg, and bandwidth of bw^in, bw^tr or bw^eg. 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 +-----+ Enc.:enc^in +-----+ Enc.:enc^tr +-----+ | |<---------//--------->| |<---------//--------->| | |SC: | Enc.: enc^tr |SC: | Enc.: enc^eg |SC: | |sc^in| BW:bw^in |sc^tr| BW:bw^tr |sc_eg| | |<---------//--------->| |<---------//--------->| | +-----+ BW: bw^tr +-----+ BW: bw^eg +-----+ Figure 1: GMPLS network model For the simplicity of the analysis in CSPF consideration, the below assumptions are made when the LSP is created. (1) Switching capability (SC) must be consistent from an ingress node to an egress node. (2) SC of transit nodes must be consistent with SC of a LSP to be created. (3) Encoding-type must be consistent along a route to be established. BW of each TE link (bw^in, bw^tr and be^eg) is minimal of unreserved bandwidth or interface switching capability description maximum LSP bandwidth [GMPLS-OSPF, OSPF-TE]. Multi-layered consideration in terms of switching capability or encoding-types will be a next step and currently out of scope of this document. 4. CSPF consideration In this section, we consider GMPLS constrains to be satisfied in different cases of transiting nodesĘ switching capability. 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 node, transiting nodes and the egress node indicated in columns next to the creating LSP, considering underlying physical constraints. Here, almost cases of T. Otani et al. Informational - Expires January 2005 4 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February 2005 GMPLS CSFP consideration are summarized in this document, however, some cases will be added in a future version. (1) TDM-switch capable +-----+---------+---------+---------+---------+-------------------+ |Case |LSP |Ingress |Transit |Egress |Remarks | +-----+---------+---------+---------+---------+-------------------+ | |SC |TDM |<=TDM* |TDM |<=TDM* | | |1|Enc|SONET/SDH|SONET/SDH|SONET/SDH|SONET/SDH| | | |BW |X |<=bw^so |<=bw^tr |<=bw^en |Specified in G.691 | +-----+---------+---------+---------+---------+-------------------+ | |SC |TDM |<=TDM* |TDM |<=TDM* | | |2|Enc|Etherner |Ethernet |Ethernet |Ethernet | | | |BW |X |<=bw^so |<=bw^tr |<=bw^en |Specified in IEEE | +-----+---------+---------+---------+---------+-------------------+ | |SC |TDM |<=TDM* |TDM |<=TDM* | | |3|Enc|OTN* |OTN* |OTN* |OTN* | | | |BW |X |<=bw^so |<=bw^tr |<=bw^en |Specified in G.709 | +-----+---------+---------+---------+---------+-------------------+ * OTN interfaces are equivalent to digital wrapper technology. * <=TDM means that the constraint contains smaller granular switching capability of PSC and L2SC, in addition to TDM. In below cases, this notation indicates the same meaning. Table 1: Desired GMPLS attributes in the case of TDM-SC In this case, since the node with TDM SC supports sub-rate switching, BW X can be equal to or less than bw^so, bw^tr and bw^en. (2) Lambda switch capable (LSC) +-----+---------+---------+---------+---------+-------------------+ |Case |LSP |Ingress |Transit |Egress |Remarks | +-----+---------+---------+---------+---------+-------------------+ | |SC |lambda |<=lambda |lambda |<=lambda |gmpls-routing-09 | |1|Enc|lambda |lambda |lambda |lambda |section 3.7, 3.10 | | |BW |X |<=bw^so |<=bw^tr |<=bw^en | | +-----+---------+---------+---------+---------+-------------------+ | |SC |lambda |<=lambda |lambda |<=lambda |gmpls-routing-09 | |2|Enc|SONET/SDH|SONET/SDH|SONET/SDH|SONET/SDH|section 3.6, 3.9 | | |BW |X |=bw^so |=bw^tr |=bw^en |Specified in G.691 | +-----+---------+---------+---------+---------+-------------------+ | |SC |lambda |<=lambda |lambda |<=lambda | | |3|Enc|Etherner |Ethernet |Ethernet |Ethernet | | | |BW |X |=bw^so |=bw^tr |=bw^en |Specified in IEEE | +-----+---------+---------+---------+---------+-------------------+ | |SC |lambda |<=lambda |lambda |<=lambda | | |4|Enc|OTN |OTN |OTN |OTN | | T. Otani et al. Informational - Expires January 2005 5 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February 2005 | |BW |X |=bw^so |=bw^tr |=bw^en |Specified in G.709 | +-----+---------+---------+---------+---------+-------------------+ Table 2: Desired GMPLS attributes in the case of LSC Because the node with lambda SC supports only optical signal switching, BW X must be equal to bw^so, bw^tr and bw^en except in the case of the encoding-type of lambda. (3) Fiber switch capable (FSC) +-----+---------+---------+---------+---------+-------------------+ |Case |LSP |Ingress |Transit |Egress |Remarks | +-----+---------+---------+---------+---------+-------------------+ | |SC |Fiber |<=Fiber |Fiber |<=Fiber |gmpls-routing-09 | |1|Enc|lambda |lambda |lambda |lambda |section 3.8 | | |BW |X |<=bw^so |<=bw^tr |<=bw^en | | +-----+---------+---------+---------+---------+-------------------+ Table 3: Desired GMPLS attributes in the case of FSC The node with fiber SC supports only optical wavelength or waveband switching, and therefore, the encoding type must be lambda and BW X must be equal to or less than bw^so, bw^tr and bw^en. (4) Layer 2 switch capable (L2SC) The guideline for the calculation must be created after the definition and discussion L2SW are settled down. (5) Packet switch capable (PSC) +-----+---------+---------+---------+---------+-------------------+ |Case |LSP |Ingress |Transit |Egress |Remarks | +-----+---------+---------+---------+---------+-------------------+ | |SC |PSC |PSC |PSC |PSC | | |1|Enc|Packet |Packet |Packet |Packet | | | |BW |X |<=bw^so |<=bw^tr |<=bw^en | | +-----+---------+---------+---------+---------+-------------------+ Table 4: Desired GMPLS attributes in the case of PSC Since the node with PSC supports only packet switching, BW X must be equal to or less than bw^so, bw^tr and bw^en. These GMPLS constraints must be considered for computing CSPF and creating GMPLS LSPs. T. Otani et al. Informational - Expires January 2005 6 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February 2005 5. Security consideration GMPLS CSPF consideration will not change the underlying security issues. 6. 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. 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. 7. 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", draft-ietf-ccamp-gmpls-routing-09.txt, October 2003. [GMPLS-OSPF] K. Kompella, and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp-ospf-gmpls-extensions- 12.txt, October 2003. [OSPF-TE] Katz, D., et al, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC3630, September 2003. Author's Addresses Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7357 Saitama, 356-8502. Japan Email: otani@kddilabs.jp Kenichi Ogaki T. Otani et al. Informational - Expires January 2005 7 Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February 2005 KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7897 Saitama, 356-8502. Japan Email: ogaki@kddilabs.jp Arthi Ayyangar Juniper Networks, Inc. 1194 N. Mathilda Ave Phone: Sunnyvale, CA 94089 Email: arthi@juniper.net Document expiration This document will be expired in Aug. 2005, unless it is updated. Copyright statement "Copyright (C) The Internet Society (year). 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. Informational - Expires January 2005 8