[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07                                       
               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