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

Versions: 00 01 02 03 04 05 06 07                                       
               IETF Internet Draft                                      Tomohiro Otani
               Proposed status: Best Current Practice                    Kenichi Ogaki
               Expires: January 2006                                     KDDI R&D Labs
                                                                        Arthi Ayyangar
                                                                      Kireeti Kompella
                                                                      Juniper Networks
                                                                         Rajiv Papneja
                                                                               Isocore
                                                                             July 2005
               
               
                        GMPLS constraints consideration for CSPF path computation
               
                        Document: draft-otani-ccamp-gmpls-cspf-constraints-01.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 (2005). 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.  Informational - Expires January 2006             1
                  Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-01.txt July 2005
               
               
               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..........................................8
                  6. Intellectual property considerations............................8
                  7. Informative references..........................................8
                  Author's Addresses.................................................9
                  Document expiration................................................9
                  Copyright statement................................................9
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
                  T. Otani et al.  Informational - Expires January 2006             2
                  Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-01.txt July 2005
               
               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.  Informational - Expires January 2006             3
                  Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-01.txt July 2005
               
               
                  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
                  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 switching capabilities for a
                  particular link [GMPLS-Routing] should be appropriately chosen as the
                  switching capability 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
                  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
               
                  T. Otani et al.  Informational - Expires January 2006             4
                  Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-01.txt July 2005
               
                  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 constrains 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 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     |<=bw        |<=bw     |Specified in G.691|
                  +-----+---------+---------+------------+---------+------------------+
                  | |SC |TDM      |<=TDM*   |TDM         |<=TDM*   |                  |
                  |2|Enc|Etherner |Ethernet |>=Ethernet  |Ethernet |                  |
                  | |BW |X        |<=bw     |<=bw        |<=bw     |Specified in IEEE |
                  +-----+---------+---------+------------+---------+------------------+
                  | |SC |TDM      |<=TDM*   |TDM         |<=TDM*   |                  |
                  |3|Enc|OTN*     |OTN*     |>=OTN*      |OTN*     |                  |
                  | |BW |X        |<=bw     |<=bw        |<=bw     |Specified in G.709|
                  +-----+---------+---------+------------+---------+------------------+
               
                  * <=TDM means that the constraint contains smaller granular switching
                  capability such as PSC or L2SC, in addition to TDM. In below cases,
                  this notation indicates the same meaning.
                  * >=SONET/SDH means the constraint contains larger granular encoding
                  types of Lambda (photonic) and Fiber, in addition to SONET/SDH. In
                  other cases, this notation indicates the same meaning.
                  *SC in LSP means a desired switching type of LSP.
                  *OTN interfaces are equivalent to digital wrapper technology.
               
                         Table 1: Desired GMPLS attributes in the case of TDM-SC
               
               
                  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. A sub.rate
               
                  T. Otani et al.  Informational - Expires January 2006             5
                  Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-01.txt July 2005
               
                  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)
               
                  +-----+---------+---------+-----------+---------+------------------+
                  |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      |=bw        |=bw      |                  |
                  +-----+---------+---------+-----------+---------+------------------+
                  | |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      |=bw        |=bw      |Specified in G.691|
                  +-----+---------+---------+-----------+---------+------------------+
                  | |SC |lambda   |<=lambda |>=lambda*  |<=lambda |                  |
                  |3|Enc|Etherner |Ethernet |>=Ethernet |Ethernet |                  |
                  | |BW |X        |=bw      |=bw        |=bw      |Specified in IEEE |
                  +-----+---------+---------+-----------+---------+------------------+
                  | |SC |lambda   |<=lambda |>=lambda*  |<=lambda |                  |
                  |4|Enc|OTN      |OTN      |>=OTN      |OTN      |                  |
                  | |BW |X        |=bw      |=bw        |=bw      |Specified in G.709|
                  +-----+---------+---------+-----------+---------+------------------+
               
                  *>=lambda means the constraint contains fiber switching capability,
                  in addition to lambda. In other cases, this notation indicates the
                  same meaning.
               
                           Table 2: Desired GMPLS attributes in the case of LSC
               
               
                  The interface with LSC supports only optical signal switching, BW X
                  must be equal to bw. In the case of a interface with a lambda
                  encoding-type and a transparent to bit-rate and framing, BW X must be
                  equal to or less than bw.
               
               
               
               
               
               
               
               
               
               
                  T. Otani et al.  Informational - Expires January 2006             6
                  Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-01.txt July 2005
               
                  (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     |<=bw       |<=bw     |                  |
                  +-----+---------+---------+-----------+---------+------------------+
               
                           Table 3: Desired GMPLS attributes in the case of FSC
               
                  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.
               
               
                  (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     |<=bw       |<=bw     |                   |
                  +-----+---------+---------+-----------+---------+-------------------+
                  | |SC |PSC      |PSC      |PSC        |PSC      |                   |
                  |2|Enc|SONET/SDH|SONET/SDH|>=SONET/SDH|SONET/SDH|                   |
                  | |BW |X        |<=bw     |<=bw       |<=bw     |                   |
                  +-----+---------+---------+-----------+---------+-------------------+
                  | |SC |PSC      |PSC      |PSC        |PSC      |                   |
                  |3|Enc|Ethernet |Ethernet |>=Ethernet |Ethernet |                   |
                  | |BW |X        |<=bw     |<=bw       |<=bw     |                   |
                  +-----+---------+---------+-----------+---------+-------------------+
               
                           Table 4: Desired GMPLS attributes in the case of PSC
               
               
                  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.
               
               
                  T. Otani et al.  Informational - Expires January 2006             7
                  Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-01.txt July 2005
               
               
               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.
               
                  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", 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.
                  [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, "LSP Hierarchy with
                                  Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-
                                  08.txt, February 2002.
               
                  T. Otani et al.  Informational - Expires January 2006             8
                  Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-01.txt July 2005
               
               
               Author's Addresses
               
                  Tomohiro Otani
                  KDDI R&D Laboratories, Inc.
                  2-1-15 Ohara Kamifukuoka-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 Kamifukuoka-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
               
                  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 January 2006, unless it is updated.
               
               
               Copyright statement
               
                  Copyright (C) The Internet Society (2005). 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,
               
                  T. Otani et al.  Informational - Expires January 2006             9
                  Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-01.txt July 2005
               
                  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 2006            10