[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07

Internet-Draft                                   Tomohiro Otani (Editor)
Intended status: Informational                    Kenichi Ogaki (Editor)
Expires: May 2008                                          KDDI R&D Labs
                                                     Daniel King(Editor)
                                                           Aria Networks

                                                        November 19 2007


       Considering Generalized Multiprotocol Label Switching Traffic
              Engineering Attributes During Path Computation

         Document: draft-otani-ccamp-gmpls-cspf-constraints-07.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 IETF Trust (2007). All Rights Reserved.

Abstract

   This document provides guidelines for the consideration of
   Generalized Multiprotocol Label Switching (GMPLS) Traffic-Engineering
   (TE) attributes for computation of routes for Label Switched Paths
   (LSPs) in a GMPLS network.
        This document summarizes how GMPLS TE attributes on ingress
   links, transit links, and egress links may be treated as path
   computation constraints to determine the route of a GMPLS Label
   Switched Path (LSP).


   T. Otani et al.           Expires May 2008                        1

   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt
                            November 2007


Table of Contents

Status of this Memo..................................................1
Abstract.............................................................1
1. Introduction......................................................3
2. Problem Statements................................................3
3. Assumed Network Model.............................................4
4. Path Computation Considerations...................................6
5. Security consideration...........................................13
6. Acknowledgements.................................................14
7. Intellectual Property Considerations.............................14
8. IANA Considerations..............................................15
9. References.......................................................15



































   T. Otani et al.           Expires  May 2008                [Page 2]

   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt
                            November 2007

1. Introduction

   A network is, in general, controlled and managed taking into account
   various attributes of the underlying technologies of the physical and
   logical links and nodes. In a network operated using Generalized
   Multiprotocol Label Switching (GMPLS) protocols, many of these
   Traffic Engineering (TE) attributes are advertised using routing
   protocols [RFC3945], [RFC4202].

        To establish a GMPLS Label Switched Path (LSP) it is necessary
   to compute a route or path for that LSP either hop-by-hop or by the
   pre-calculation of part or all of the path. In order that the route
   selected is capable of satisfying the requirements of the user or
   application that will use the LSP the computation must be constrained
   by a set of LSP-specific requirements and the TE attributes
   advertised within the network. Further, considerations of technology
   and node or link capabilities may also provide restrictions to the
   feasibility of LSP establishment on certain routes, and this can be
   deduced from the TE attributes advertised within the network and used
   by the path computation algorithms to select only viable routes.

        In a mixed, integrated network (for example, one containing
   optical switches and packet routers) these constraints may vary and
   are understood differently for different equipment and different LSPs.
   This document provides guidelines to facilitate path computation for
   GMPLS LSPs by summarizing how GMPLS TE attributes on ingress links,
   transit links, and egress links may be treated as path computation
   constraints to determine the route of a GMPLS Label Switched Path
   (LSP).

2. Problem Statements

   A GMPLS network is assumed to be composed of different switching
   capabilities for nodes and different encoding types for TE links.
   Such a GMPLS network is usually deployed by adopting multiple vendors
   and each vendor usually has each constraint for a CSPF path
   calculation and then a problem appears that a signaling message
   including a calculated route at an ingress node may be rejected at a
   transit node and the path creation may fail because of the difference
   of the constraint for a CSPF path calculation between these nodes.

   In an example network as shown in Figure 1, when ingress Router1
   calculates a path to egress Router2 without considering the encoding
   type for transit TE links and sends path message to PXC1, PXC1
   returns path error message to Router1 because PXC1 cannot
   crossconnect from ethernet encoding link to sonet/sdh encoding link.
   In this case, if ingress Router1 can calculate with the exact match
   for all the links through the ingress node to the egress node, the
   path can be established.


   T. Otani et al.           Expires  May 2008                [Page 3]

   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt
                            November 2007


     Router1--(Ethernet)--PXC1--(SONET/SDH)--PXC2--(Ethernet)--Router2

   *(): Encoding type
                          Figure 1: example network1


   On the other hand, when a network includes optical switching nodes
   such as ROADMs which have a link with the encoding type of lambda
   between nodes as shown in Figure2 and ingress Router1 calculate with
   the exact match through all the links, the path calculation will fail.
   In this environment, even if the encoding type of ingress and egress
   links is different from transit links, the path should be established.
   Therefore, constraints for various cases of path calculation must be
   clearly defined.


             Router1                                          Router3
                \                                              /
                 \                                            /
               (Ethernet)                              (Ethernet)
                   \                                        /
                    \                                      /
                    ROADM1--(Lambda)--ROADM2--(Lambda)--ROADM3
                    /                                      \
                   /                                        \
               (SONET/SDH)                             (SONET/SDH)
                 /                                            \
                /                                              \
             Router2                                          Router4

                          Figure 2: example network2


3. Assumed Network Model

   3.1 GMPLS TE Attributes Consideration for Path Calculation

   For path computation to establish GMPLS LSPs correctly, various GMPLS
   attributes [RFC4202], [RFC4203] 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
   [RFC3630].

        (1) Encoding-type: Synchronous Optical Network
        (SONET)/Synchronous Digital Hierarchy (SDH), Lambda, Ethernet,
        etc.
        (2) Switching capability: Time Division Multiplex (TDM), Lambda,
        Fiber, etc.
        (3) Bandwidth: OC-192, OC-48, GbE, 10GbE, etc.

   T. Otani et al.           Expires  May 2008                [Page 4]

   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt
                            November 2007


   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.


   3.2 Considered Network Model

   Figure 3 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 path computation. Each link 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 maybe applicable to an inter-domain GMPLS networks.

             Ingress             Transit             Egress
   +-----+   link1-2   +-----+   link2-3   +-----+   link3-4   +-----+
   |Node1|------------>|Node2|------------>|Node3|------------>|Node4|
   |     |<------------|     |<------------|     |<------------|     |
   +-----+   link2-1   +-----+   link3-2   +-----+   link4-3   +-----+

                       Figure 3: GMPLS Network Model


   For the simplicity of the analysis in path 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.

  A GMPLS network maybe a multi-layer network, which is composed of
  multiple nodes with different switching capabilities and interface
  encoding types. Therefore, a hierarchical structure may be considered
  in 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

   T. Otani et al.           Expires  May 2008                [Page 5]

   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt
                            November 2007

  acceptable. One of advertised multiple interface switching capability
  descriptors for the same link [RFC4202] 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
   [RFC4203], 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.

   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. Path Computation Considerations

        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 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 path computation
   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     |                  |

   T. Otani et al.           Expires  May 2008                [Page 6]

   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt
                            November 2007

   +---+---------+---------+------------+---------+------------------+

   *SC in LSP means a desired switching type of LSP.
   *OTN interfaces are equivalent to digital wrapper technology in this
   document.
   * BW is the desired bandwidth of the LSP
   * bw is the bandwidth available on the link

   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. 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: The Case of End-Point(Ingress/Egress) Link Attributes
                          without Lambda Encoding

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


   T. Otani et al.           Expires  May 2008                [Page 7]

   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt
                            November 2007

   If an interface supports only a specific bit-rate and format such as
   SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to
   match bit-rate and its framing.

   *In the case of an interface with a lambda encoding and a transparent
   to bit-rate and framing, BW X must be equal to or less than bw.







        Table 2.2: The Case of End-Point(Ingress/Egress) Link Attributes
                           with Lambda Encoding

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

   If an interface supports only a specific bit-rate and format such as
   SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to
   match bit-rate and its framing.

   *In the case of an interface with a lambda encoding and a transparent
   to bit-rate and framing, BW X must be equal to or less than bw.



   T. Otani et al.           Expires  May 2008                [Page 8]

   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt
                            November 2007














           Table 2.3: The Case of One End-Point (Ingress/Egress) Link
                      Attribute with Lambda Encoding

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

   The case of ingress link with the specific encoding and egress link
   with lambda encoding also follows the same manner.

   If an interface supports only a specific bit-rate and format such as
   SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to
   match bit-rate and its framing.

   *In the case of an interface with a lambda encoding and a transparent
   to bit-rate and framing, BW X must be equal to or less than bw.


   T. Otani et al.           Expires  May 2008                [Page 9]

   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt
                            November 2007














   (3) Fiber Switch Capable (FSC)

     Table 3.1: The Case of End-Point(Ingress/Egress) Link Attributes
                     without Lambda or Fiber Encoding

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

   If an interface supports only a specific bit-rate and format such as
   SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to
   match bit-rate and its framing.

   T. Otani et al.           Expires  May 2008               [Page 10]

   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt
                            November 2007


   *In the case of an interface with a lambda or fiber encoding and a
   transparent to bit-rate and framing, BW X must be equal to or less
   than bw.









   Table 3.2: The Case of End-Point(Ingress/Egress) Link Attributes with
                         Lambda or Fiber Encoding

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


   T. Otani et al.           Expires  May 2008               [Page 11]

   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt
                            November 2007

   If an interface supports only a specific bit-rate and format such as
   SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to
   match bit-rate and its framing.

   *In the case of an interface with a lambda or fiber encoding and a
   transparent to bit-rate and framing, BW X must be equal to or less
   than bw.






   Table 3.3: The Case of One End-Point (Ingress/Egress) Link Attribute
                       with Lambda or Fiber Encoding

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

   The case of ingress link with the specific encoding and egress link
   with lambda encoding also follows as the same manner.




   T. Otani et al.           Expires  May 2008               [Page 12]

   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt
                            November 2007

   If an interface supports only a specific bit-rate and format such as
   SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to
   match bit-rate and its framing.

   *In the case of an interface with a lambda encoding and a transparent
   to bit-rate and framing, BW X must be equal to or less than bw.

   Although the interface with FSC can switch the entire contents to
   another interface, this interface should only be used for optical
   wavelength or waveband switching.





   (4) Layer 2 Switch Capable (L2SC)

   The guideline for the calculation must be created after the
   definition and discussion about L2SW are settled down.

   (5) Packet Switch Capable (PSC)

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

   This document does not discuss domain based multilayer path
   computation considerations where specific routing policies, which are
   sometimes independent from the underlying domains and sometimes take
   the underlying domains' policies into consideration, are required.


5. Security consideration



   T. Otani et al.           Expires  May 2008               [Page 13]

   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt
                            November 2007

        Anything that can be done to change the output of a path
   computation algorithm can significantly affect the operational
   stability of a network, could force traffic to traverse undesirable
   or costly links, and could place data into less secure parts of the
   network. Therefore, the integrity of the path computation mechanism
   is very significant in a GMPLS network.

        The path computation algorithm, itself, and the mechanisms for
   conveying computed paths to and between the LSRs in the network are
   out of scope for this document. But misuse or confusion with respect
   of the handling of the attributes described in this document could
   leave a network open to various security attacks. In particular, if
   there is a known mismatch between the interpretation or handling of
   TE attributes within a network this might be exploited by an attacker
   to cause disruption or to waste network resources in an integrated
   multi-technology network. Therefore, network operators are
   Recommended to use a consistent approach across the whole network.

6. Acknowledgements

   Thanks to Adrian Farrel for his review of this document.

7. Intellectual Property Considerations

        The IETF takes no position regarding the validity or scope of
   any Intellectual Property Rights 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; nor does it represent
   that it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC documents
   can be found in BCP 78 and BCP 79.

        Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
   http://www.ietf.org/ipr.

        The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.






   T. Otani et al.           Expires  May 2008               [Page 14]

   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt
                            November 2007

8. IANA Considerations

   This document does not require any IANA consideration.

9. References

9.1 Normative References

  [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.
  [RFC4202]      K. Kompella and Y. Rekhter, "Routing Extensions in
                  Support of Generalized Multi-Protocol Label Switching",
                 RFC4202, October 2005.
  [RFC4203]      K. Kompella and Y. Rekhter, "OSPF Extensions in
                  Support of Generalized Multi-Protocol Label Switching",
                 RFC4203, October 2005.

9.2 Informative References

  [RFC3477]      K. Kompella and Y. Rekhter, "Signalling Unnumbered
                  Links in Resource ReSerVation Protocol - Traffic
                  Engineering (RSVP-TE)", RFC3477, January 2003.
  [RFC3630]      Katz, D., et al, "Traffic Engineering (TE) Extensions
                  to OSPF Version 2", RFC3630, September 2003.
  [RFC3945]      E. Mannie, "Generalized Multi-Protocol Label Switching
                  Architecture", RFC3945, October, 2004.


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
   Nuova Systems
   2600 San Tomas Expressway
   Santa Clara, CA  95051
   Email: arthi@nuovasystems.com


   T. Otani et al.           Expires  May 2008               [Page 15]

   Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt
                            November 2007

   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

   Daniel King
   Aria Networks Ltd.
   44-45 Market Place
   Chippenham, SN153HU UK
   EMail: daniel.king@aria-networks.com

Document expiration

   This document will be expired in May 2008, unless it is updated.


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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  May 2008               [Page 16]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/