[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: Standards Track                          Kenichi Ogaki
Expires: October 2006                                     KDDI R&D Labs
                                                         Arthi Ayyangar
                                                       Kireeti Kompella
                                                       Juniper Networks
                                                          Rajiv Papneja
                                                                Isocore
                                                             April 2006


         GMPLS constraints consideration for CSPF path computation

         Document: draft-otani-ccamp-gmpls-cspf-constraints-03.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 (2006). 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.           Expires October 2006                    1
   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-03.txt April
   2006


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..........................................9
   6. Intellectual property considerations............................9
   7. Informative references.........................................10
   Author's Addresses................................................10
   Document expiration...............................................11
   Copyright statement...............................................11


































   T. Otani et al.           Expires October 2006                    2
   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-03.txt April
   2006

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.           Expires October 2006                    3
   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-03.txt April
   2006



   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
   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.

  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 interface switching capability
  descriptors for the same link [GMPLS-Routing] 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
   [GMPLS-OSPF], 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.


   T. Otani et al.           Expires October 2006                    4
   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-03.txt April
   2006

   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.


4. CSPF consideration

   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 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 CSPF consideration are
   summarized in this document, however, some cases will be added in a
   future version.


   (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
   draft.


   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

   T. Otani et al.           Expires October 2006                    5
   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-03.txt April
   2006

   in the interface switching capability descriptor. A 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 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)

   Table 2.1: Desired GMPLS attributes in the case of LSC without lambda
                                 encoding

   +-------------+---------+------------+---------+------------------+
   |LSP attribute|Ingress  |Transit     |Egress   |Remarks           |
   +---+---------+---------+------------+---------+------------------+
   |   |         |LSC      |            |LSC      |                  |
   |   |         +---------+            +---------+                  |
   |SC |LSC      |TDM      |LSC         |TDM      |                  |
   |   |         +---------+            +---------+                  |
   |   |         |L2SC     |            |L2SC     |                  |
   |   |         +---------+            +---------+                  |
   |   |         |PSC      |            |PSC      |                  |
   +---+---------+---------+------------+---------+[GMPLS-Routing]   |
   |   |SONET/SDH|SONET/SDH|SONET/SDH   |SONET/SDH|section 3.6, 3.9  |
   |   +---------+---------+------------+---------+Specified in G.691|
   |Enc|Ethernet |Ethernet |Ethernet    |Ethernet |Specified in IEEE |
   |   +---------+---------+------------+---------+                  |
   |   |OTN      |OTN      |OTN         |OTN      |Specified in G.709|
   |---+---------+---------+------------+---------+------------------+
   |BW |X        |=bw      |=bw         |=bw      |                  |
   +---+---------+---------+------------+---------+------------------+
   The interface with LSC supports only optical signal switching, BW X
   must be equal to bw so as to match bit-rate and its framing.















   T. Otani et al.           Expires October 2006                    6
   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-03.txt April
   2006


    Table 2.2: Desired GMPLS attributes in the case of LSC with lambda
                                 encoding

   +-------------+---------+------------+---------+------------------+
   |LSP attribute|Ingress  |Transit     |Egress   |Remarks           |
   +---+---------+---------+------------+---------+------------------+
   |   |         |LSC      |            |LSC      |                  |
   |   |         +---------+            +---------+                  |
   |SC |LSC      |TDM      |LSC         |TDM      |                  |
   |   |         +---------+            +---------+                  |
   |   |         |L2SC     |            |L2SC     |                  |
   |   |         +---------+            +---------+                  |
   |   |         |PSC      |            |PSC      |                  |
   +---+---------+---------+------------+---------+                  |
   |   |lambda   |         |            |         |[GMPLS-Routing]   |
   |   +---------+         |            |         |section 3.7, 3.10 |
   |Enc|SONET/SDH|         |            |         |Specified in G.691|
   |   +---------+lambda   |lambda      |lambda   |                  |
   |   |Ethernet |         |            |         |Specified in IEEE |
   |   +---------+         |            |         |                  |
   |   |OTN      |         |            |         |Specified in G.709|
   +---+---------+---------+------------+---------+                  |
   |BW |X        |<=bw     |<=bw        |<=bw     |                  |
   +---+---------+---------+------------+---------+------------------+
   In the case of an interface with a lambda encoding-type and a
   transparent to bit-rate and framing, BW X must be equal to or less
   than bw.





















   (3) Fiber switch capable (FSC)

   T. Otani et al.           Expires October 2006                    7
   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-03.txt April
   2006


           Table 3: Desired GMPLS attributes in the case of FSC

   +---+---------+---------+------------+---------+------------------+
   |LSP attribute|Ingress  |Transit     |Egress   |Remarks           |
   +---+---------+---------+------------+---------+------------------+
   |   |         |FSC      |            |FSC      |                  |
   |   |         +---------+            +---------+                  |
   |   |         |LSC      |            |LSC      |                  |
   |   |         +---------+            +---------+                  |
   |SC |FSC      |TDM      |FSC         |TDM      |                  |
   |   |         +---------+            +---------+                  |
   |   |         |L2SC     |            |L2SC     |                  |
   |   |         +---------+            +---------+                  |
   |   |         |PSC      |            |PSC      |                  |
   +---+---------+---------+------------+---------+[GMPLS-Routing]   |
   |   |fiber    |fiber    |fiber       |fiber    |section 3.8       |
   |   +---------+---------+------------+---------+                  |
   |   |lambda   |lambda   |lambda      |lambda   |section 3.7, 3.10 |
   |   |         |or fiber |or fiber    |or fiber |                  |
   |   +---------+---------+------------+---------+                  |
   |Enc|         |SONET/SDH|SONET/SDH   |SONET/SDH|section 3.6, 3.9  |
   |   |SONET/SDH|, lambda |, lambda    |, lambda |Specified in G.691|
   |   |         |or fiber |or fiber    |or fiber |                  |
   |   +---------+---------+------------+---------+                  |
   |   |         |Ethernet,|Ethernet,   |Ethernet,|Specified in IEEE |
   |   |Ethernet |lambda   |lambda      |lambda   |                  |
   |   |         |or fiber |or fiber    |or fiber |                  |
   |   +---------+---------+------------+---------+                  |
   |   |         |OTN,     |OTN,        |OTN,     |Specified in G.709|
   |   |OTN      |lambda   |lambda      |lambda   |                  |
   |   |         |or fiber |or fiber    |or fiber |                  |
   +---+---------+---------+------------+---------+                  |
   |BW |X        |<=bw     |<=bw        |<=bw     |                  |
   +---+---------+---------+------------+---------+------------------+


   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)

   T. Otani et al.           Expires October 2006                    8
   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-03.txt April
   2006


           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 CSPF and
   creating GMPLS LSPs.


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.



   T. Otani et al.           Expires October 2006                    9
   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-03.txt April
   2006

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", RFC4202, October 2005.
  [GMPLS-OSPF]   K. Kompella and Y. Rekhter, "OSPF Extensions in
                  Support of Generalized Multi-Protocol Label
                  Switching", RFC4203, October 2005.
  [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, "Label Switched Paths
                  (LSP) Hierarchy with Generalized Multi-Protocol Label
                  Switching (GMPLS) Traffic Engineering (TE)", RFC4204,
                  October 2005.

Author's 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
   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


   T. Otani et al.           Expires October 2006                   10
   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-03.txt April
   2006

   Kireeti Kompella
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA 94089 US
   Email: kireeti@juniper.net


Document expiration

   This document will be expired in April 2006, unless it is updated.


Copyright statement

   Copyright (C) The Internet Society (2006). 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.           Expires October 2006                   11