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