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

Versions: 00 01 02 03 04 05 06 07

INTERNET-DRAFT                                                 T. Otani
Intended status: Informational                               S. Okamoto
Expires:June 2008                                         KDDI R&D Labs
                                                             S. Okamoto
                                                        Keio University
                                                             W. Imajuku
                                                                    NTT
                                                      December 18, 2007


            GMPLS Inter-domain Traffic Engineering Requirements

            Document: draft-otani-ccamp-interas-gmpls-te-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.


Abstract

   This draft provides requirements for the support of generalized
   multi-protocol label switching (GMPLS) inter-domain traffic
   engineering (TE). Its main objective is to present the differences
   between MPLS inter-domain TE and GMPLS inter-domain TE. This draft
   covers not only GMPLS Inter-domain architecture but also functional
   requirements in terms of GMPLS signaling and routing in order to
   specify these in a GMPLS Inter-domain environment.


Table of Contents

   Status of this Memo................................................ 1
   Abstract........................................................... 1
   1. Introduction.................................................... 3

T. Otani et al.   Informational - Expires June 2008            [Page 1]


Internet Drafts  draft-otani-ccamp-interas-gmpls-te-07.txt    Dec. 2007

   2. Conventions used in this document............................... 3
   3. Assumed network model........................................... 4
   4. Requirement of exchanging TE information across domain boundaries6
   5. Requirement for GMPLS inter-domain TE signaling, routing and
   management......................................................... 9
   6. Security consideration......................................... 14
   7. Acknowledgement................................................ 14
   8. Intellectual property considerations........................... 14
   9. Informative references......................................... 15
   Author's Addresses................................................ 15
   Document expiration............................................... 16
   Copyright statement............................................... 16

T. Otani et al.   Informational - Expires June 2008            [Page 2]


Internet Drafts  draft-otani-ccamp-interas-gmpls-te-07.txt    Dec. 2007

1. Introduction

   Initial efforts of MPLS/GMPLS traffic engineering mechanism were
   focused on solving the problem within an Autonomous System (AS).
   Service Providers (SPs) have come up with requirements for extending
   TE mechanisms across the domains (ASes as well as areas) [Inter-
   domain]. It discusses requirements for inter-domain Traffic
   Engineering mechanism with focus on packet MPLS networks and GMPLS
   packet switch capable (hereinafter MPLS). This document complements
   [Inter-domain] by providing some consideration for non-packet switch
   capable GMPLS networks (hereinafter GMPLS) scalability and
   operational efficiency in such a networking environment.

   TE information exchanged over domains for signaling and routing GMPLS
   Label Switched Paths (LSPs) is more stringent than that of MPLS LSPs
   [MPLS-AS] from the point of an effective operation. This is because
   in order to dynamically or statically establish GMPLS LSPs, the
   additional TE information, e.g., interface switching capability, link
   encoding, protection, and so forth must be considered. Operators may
   use different switching capable nodes and TE links with different
   encoding type and bandwidth, decided by their business strategy and
   such TE information exchange is expected to improve operational
   efficiency in GMPLS-controlled networks.

   In terms of signaling, GMPLS signaling must operate over multiple
   domains using routing information, exchanged TE information or a
   statistically configured domain-to-domain route. This signaling
   request should take into account bi-directionality, switching
   capability, encoding type, SRLG, and protection attributes of the TE
   links spanned by the path, as well as LSP encoding type and switching
   type for the end points. Furthermore, GMPLS LSP nesting may be
   applicable at the GMPLS domain borders and should be considered
   accordingly.

   This document provides the requirements for the support of GMPLS
   inter-domain TE, investigates the necessity of dynamic or static TE
   information exchange between GMPLS-controlled domains and describes
   the TE link parameters for this routing operation.  This document
   also outlines GMPLS inter-domain architecture, and provides
   functional requirements in terms of GMPLS signaling, routing and
   management in order to specify these in a GMPLS inter-domain
   environment.


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





T. Otani et al.   Informational - Expires June 2008            [Page 3]


Internet Drafts  draft-otani-ccamp-interas-gmpls-te-07.txt    Dec. 2007

3. Assumed network model

   3.1 GMPLS inter-domain network model

   Figure 1 depicts a typical network, consisting of several GMPLS
   domains, assumed in this document. D1, D2, D3 and D4 have multiple
   GMPLS inter-domain connections, and D5 has only one GMPLS inter-
   domain connection. These domains follow the definition in [inter-
   domain].


                    +---------+
          +---------|GMPLS  D2|----------+
          |         +----+----+          |
     +----+----+         |          +----+----+   +---------+
     |GMPLS  D1|         |          |GMPLS  D4|---|GMPLS  D5|
     +----+----+         |          +----+----+   +---------+
          |         +----+----+          |
          +---------|GMPLS  D3|----------+
                    +---------+

                Figure 1: GMPLS Inter-domain network model

   Each domain is configured using various switching and link
   technologies defined in [Arch] and an end-to-end route needs to
   respect TE link attributes like multiplexing type, encoding type,
   etc., making the problem a bit different from the case of classical
   (packet) MPLS. In order to route from one GMPLS domain to another
   GMPLS domain appropriately, each domain needs to advertise additional
   TE information, while concealing its internal topology information.
   In addition, a signaling mechanism is required to specify a route
   consisting of multiple domains, while respecting the end-point's
   encoding, switching and payload type. Section 4 describes the TE link
   attributes that need to be exchanged across the domain boundary in
   detail.

   3.2 Comparison between a GMPLS inter-domain and a MPLS inter-domain

   (1) GMPLS network model

   To investigate the difference between a GMPLS inter-domain and an
   MPLS inter-domain network, we assume the network model shown in Fig.
   2. Without loss of generality, this network model consists of two
   GMPLS domains. The GMPLS domain border nodes (A3, A4, B1, B2) are
   connected via traffic engineering (TE) links (A3-B1 and A4-B2). These
   inter-domain TE links are assumed to have a certain amount of
   bandwidth (bw), e.g., 2.5Gbit/s, 10Gbit/s, etc. Moreover, each nodes
   in both domain 1 and domain 2 can support x and y switching
   capabilities (e.g., x or y means TDM, Lambda or fiber). The edge node
   of the network (possibly A1, A2, B3, and B4) may also have the
   switching capability of packet (PSC1-4). Moreover, each TE link has a
   z or w encoding type (z or w means SONET/SDH, Lambda, Ethernet, etc.).



T. Otani et al.   Informational - Expires June 2008            [Page 4]


Internet Drafts  draft-otani-ccamp-interas-gmpls-te-07.txt    Dec. 2007

                                   |
  +-------+   z-enc. +-------+   z-enc.  +-------+   z-enc. +-------+
  |A1,x-SC|----//----|A3,x-SC|-----------|B1,y-SC|----//----|B3,y-SC|
  +-------+   bw-1   +-------+    bw-1   +-------+   bw-1   +-------+
      |                  |         |         |                  |
      =bw-1              =bw-1     |         =bw-1              =bw-1
      |z-enc.            |z-enc.   |         |z-enc.            |z-enc.
      |                  |         |         |                  |
  +-------+   w-enc. +-------+   w-enc.  +-------+   w-enc. +-------+
  |A2,x-SC|----//----|A4,x-SC|-----------|B2,y-SC|----//----|B4,y-SC|
  +-------+   bw-2   +-------+    bw-2   +-------+   bw-2   +-------+
                                   |
          GMPLS domain 1           |          GMPLS domain 2


              Figure 2: GMPLS Inter-domain network model (1)


   Between GMPLS domain border nodes, the routing information is
   statically or dynamically exchanged. Link management protocol (LMP)
   [LMP] may be applied to maintain and manage TE links between GMPLS
   domain border nodes.

   In general, the switching capability at each end of two TE-Links (A3-
   B1 and A4-B2) between domain border nodes shall not be always same.
   Therefore, GMPLS nodes shall need to identify the attributes of these
   TE-Links in order to create LSP over multiple domains. At present,
   GMPLS/ MPLS technology does not provide the functionality to
   discriminate such attributes through a flooding mechanism.
   Furthermore, these GMPLS specific requirements for inter-domain
   traffic engineering are not described in [Inter-domain].

   (2) MPLS network model

   In the packet MPLS network, we can assume the MPLS inter-domain
   network model as shown in Figure 3. There are no routing constraints
   such as switching capability and encoding type, compared to the GMPLS
   inter-domain network model. All nodes have the same switching
   capability of packet, therefore there is no need to distribute
   switching capability information between the domains.

                                   |
         +----+          +----+    |    +----+          +----+
         | A1 |----//----| A3 |---------| B1 |----//----| B3 |
         +----+   2.5G   +----+   2.5G  +----+   2.5G   +----+
            |               |      |        |               |
            =2.5G           =2.5G  |        =2.5G           =2.5G
            |               |      |        |               |
         +----+          +----+    |    +----+          +----+
         | A2 |----//----| A4 |---------| B2 |----//----| B4 |
         +----+   10G    +----+   10G   +----+   10G    +----+
                                   |
              MPLS domain 1        |        MPLS domain 2


T. Otani et al.   Informational - Expires June 2008            [Page 5]


Internet Drafts  draft-otani-ccamp-interas-gmpls-te-07.txt    Dec. 2007

                 Figure 3: MPLS Inter-domain network model
   In the following section, we consider an MPLS or GMPLS path setup
   from an edge node in domain 1 to an edge node in domain 2.


4. Requirement of exchanging TE information across domain boundaries

   In this section, we describe the TE attributes that needs to be
   exchanged across the domain boundaries for computation of GMPLS Paths.

   4.1 Interface Switching Capability

   A constraint of bandwidth in a GMPLS controlled network is different
   from that in an IP/MPLS network. In Figure 3, two TE links with
   different values of bandwidth such as 2.5Gbit/s and 10Gbit/s are
   assumed. If an MPLS LSP with 2.5Gbit/s bandwidth is established from
   A2 to B4 in Figure 3, two sets of TE links (that is two possible
   paths) can be selected (A2-A4-B2-B4 and A2-A1-A3-B1-B3-B4).

   In the case of inter-domain GMPLS, the ingress node needs to know the
   switching capabilities supported in each domain, while computing a
   route for a GMPLS-LSP across multiple domains. If the switching
   capabilities are exchanged across the domain boundaries, the ingress
   node can determine the appropriate next-hop domain that is capable of
   supporting the requesting switching capability.

   In the example of Figure 4, we assume a switching capability as
   lambda and an encoding type as lambda. The bandwidth of each TE link
   is, for example, corresponding to the transponder's bit rate of each
   DWDM channel. In this case, both inter-domain links may be acceptable
   from A2 to B4 if only TE information within each domain is considered.
   However, a GMPLS LSP with 2.5Gbit/s bandwidth can not be established
   over a set of TE links (A2-A4-B2-B4) because all nodes support only
   LSC which can not deal with sub-rate switching, and the 10Gbit/s TE
   link can only support a GMPLS LSP with 10Gbit/s. The set of TE links
   (A2-A1-A3-B1-B3-B4) must be used instead so as to route it over the
   inter-domain link of A3-B1.

   If multiple GMPLS routes exist for a given destination via different
   domains, a path should be selected satisfying these routing
   constraints, in addition to the conventional attributes which the
   intra-domain routing protocols.  LMP protocol may assist to know
   attributes of the neighbor node, but it does not assure such
   attributes learned from LMP are consistent within the domain.
   Although an operator may want to specify a domain border node
   explicitly for such a destination, this TE information exchange will
   improve operational efficiency in GMPLS-controlled networks.
   Therefore, not only intra-domain routing protocols [GMPLS-Routing]
   but also inter-domain routing protocol needs to advertise some TE
   parameters.





T. Otani et al.   Informational - Expires June 2008            [Page 6]


Internet Drafts  draft-otani-ccamp-interas-gmpls-te-07.txt    Dec. 2007


                                    |
     +------+   2.5G   +------+   2.5G    +------+   2.5G   +------+
     |A1,LSC|----//----|A3,LSC|-----------|B1,LSC|----//----|B3,LSC|
     +------+  Lambda  +------+  Lambda   +------+  Lambda  +------+
        |                  |        |         |                 |
    2.5G=Lambda        2.5G=Lambda  |      10G=Lambda       2.5G=Lambda
        |                  |        |         |                 |
     +------+    10G   +------+    2.5G    +------+   10G    +------+
     |A2,LSC|----//----|A4,LSC|-----------|B2,LSC|----//----|B4,LSC|
     +------+  Lambda  +------+  Lambda   +------+  Lambda  +------+
                                    |
           GMPLS domain 1           |          GMPLS domain 2


              Figure 4: GMPLS inter-domain network model (2)


   4.2 Bandwidth Policy

   The advertisement of the bandwidth for traversing non-local domains
   is strongly dependent on the operational policy in each GMPLS domain.
   The resource available for different domains may be advertised over
   GMPLS inter-domain boundaries, although the actual local bandwidth is
   more than that for different domains. The GMPLS domain border nodes
   have the functionality to control the advertised resource bandwidth
   to reach a destination. For example, even if 4 times OC-48 bandwidth
   exists to a destination in one GMPLS domain, the domain may advertise
   only twice OC-48 bandwidth to another GMPLS domain, following the
   mutual policy between these two domains.  Thus, inter-domain
   reachability information may need to be enhanced to include bandwidth
   information, however, such flooding information may degrade the
   network scalability, and policy features at the border node may be
   useful not so as to maintain the same scalability of a single domain.

   4.3 Encoding type

   In addition of the link switching type, an end-to-end GMPLS LSP needs
   to have the same encoding type at all intermediate hops. In this
   section, we discuss the need for exchanging link encoding types
   across the domain boundaries.

   The example depicted in Figure 5 is considered where TE links with a
   different encoding type in a GMPLS Inter-domain network are assumed.
   In this case, differing from the case of a packet MPLS inter-domain
   network, a GMPLS LSP with a specific encoding type must be
   established to satisfy this constraint. Since physical layer
   technologies used to form TE links limit the signal encoding type to
   be transported, the ingress node should consider this by obtaining TE
   parameters exchanged between GMPLS-controlled inter-domains. In this
   case, both inter-domain links may be acceptable for routing from A2
   to B4 if only TE information within each domain is considered. The
   set of TE links (A2-A1-A3-B1-B3-B4) must be used instead so as to
   route over the inter domain-link of A3-B1, satisfying the constraint

T. Otani et al.   Informational - Expires June 2008            [Page 7]


Internet Drafts  draft-otani-ccamp-interas-gmpls-te-07.txt    Dec. 2007

   of the encoding type. Therefore, inter-domain reachability
   information needs to be enhanced to include encoding type information.

                                  |
   +------+          +------+     |     +------+          +------+
   |A1,LSC|----//----|A3,LSC|-----------|B1,LSC|----//----|B3,LSC|
   +------+   SONET  +------+   SONET   +------+   SONET  +------+
      |                  |        |        |                 |
      =SONET             =SONET   |        =lambda           =SONET
      |                  |        |        |                 |
   +------+          +------+     |     +------+          +------+
   |A2,LSC|----//----|A4,LSC|-----------|B2,LSC|----//----|B4,LSC|
   +------+  lambda  +------+   SONET   +------+  lambda  +------+
                                  |
         GMPLS domain 1           |          GMPLS domain 2


              Figure 5: GMPLS inter-domain network model (3)


   4.4 Hybrid case

   In Figure 6, we consider a mixed case of 4.1, 4.2 and 4.3, and assume
   two domains: Domain 1 consisting of GMPLS nodes with TDM-SC and TE
   links with SONET/SDH encoding type, and domain 2 consisting of GMPLS
   nodes with LSC and TE links with lambda encoding type. GMPLS nodes in
   domain 2 support sub-rate switching, for example, of 2.5Gbit/s.


                                    |
     +------+   2.5G   +------+    2.5G   +------+    2.5G  +------+
     |A1,TSC|----//----|A3,TSC|-----------|B1,LSC|----//----|B3,LSC|
     +------+  SONET   +------+   SONET   +------+  Lambda  +------+
        |                  |        |         |                 |
    2.5G=SONET         2.5G=SONET   |      10G=Lambda       2.5G=Lambda
        |                  |        |         |                 |
     +------+   10G    +------+    2.5G   +------+    10G   +------+
     |A2,TSC|----//----|A4,TSC|-----------|B2,LSC|----//----|B4,LSC|
     +------+  SONET   +------+   SONET   +------+  Lambda  +------+
                                    |
           GMPLS domain 1           |          GMPLS domain 2


              Figure 6: GMPLS Inter-domain network model (4)


   If a GMPLS LSP with 2.5Gbit/s is established from A2 to B4, the
   ingress node should know not only the reachability of B4 in domain 2,
   but also the switching capability of nodes in domain 2.  In this case,
   both inter-domain links may be acceptable for routing from A2 to B4
   if only TE information within each domain is considered. However,
   since the switching capability supported in each domain is different,
   the set of TE links (A2-A1-A3-B1-B3-B4) must be used so as to route
   over the inter domain-link of A3-B1. Therefore, an end-point

T. Otani et al.   Informational - Expires June 2008            [Page 8]


Internet Drafts  draft-otani-ccamp-interas-gmpls-te-07.txt    Dec. 2007

   (reachability) list such as node IDs, interface addresses, interface
   IDs per switching capability is very useful and may be advertised
   over GMPLS domains.

   4.5 SRLG

   To configure a secondary LSP in addition to a primary LSP over
   multiple GMPLS domains, the parameter of Shared Risk Link Group
   (SRLG) is very significant. By introducing this parameter, the source
   node can route these LSPs so as to across the different domain border
   node as well as satisfy a SRLG constraint. Although this SRLG is
   supported and defined within domains, the mechanism to maintain
   consistency of SRLG must be considered in a GMPLS inter-domain TE
   environment.

   There are cases where two different SPs may be sharing the same fate
   (facility) for TE links within domains administrated by them. However,
   presently there is no mechanism to allow SRLG to have global
   significance; SRLG administration is completely up to interconnected
   SPs.

   In this document we identify that, in order to guarantee the SRLG
   diversity requirement, the SRLGs in an inter-domain TE environment
   are required to be globally unique.

   4.6 Protection Type

   To guarantee the GMPLS LSP's resiliency over multiple GMPLS domains,
   the protection type in each domain should be carefully selected so as
   to satisfy resilient requirement of the LSP as an end-to-end manner.
   This enables us to establish a LSP with a protection mechanism per
   domain-basis, such as link or node protection. Each GMPLS domain will
   provide a type of the protection to a destination within itself.
   Otherwise, an end-to-end recovery may be provided by calculating at
   the source node with the consideration of SRLG. As the same with the
   SRLG case, protection type administration is also up to the
   interconnected SPs. Therefore, inter-domain reachability information
   needs to be enhanced to include protection type information.


5. Requirement for GMPLS inter-domain TE signaling, routing and
management

   5.1 Requirement for GMPLS inter-domain signaling for the support of
   TE

   GMPLS inter-domain signaling should establish GMPLS LSPs over GMPLS
   multiple domains relying on a dynamic calculation of the domain-to-
   domain route and GMPLS domain border nodes by path computation
   functions spread through the domains. It also should support to
   explicitly specify domain-to-domain routes, domain border nodes or
   GMPLS nodes. Moreover, specifying loose GMPLS nodes including GMPLS
   domain border nodes must be supported in GMPLS signaling. The domain
   border node received GMPLS signaling message from a source node in a

T. Otani et al.   Informational - Expires June 2008            [Page 9]


Internet Drafts  draft-otani-ccamp-interas-gmpls-te-07.txt    Dec. 2007

   different domain should support recalculation mechanisms to specify
   the route within its domain, such as RSVP route expansion technique,
   followed by GMPLS inter-domain path computation.

   5.1.1 GMPLS per-domain basis path calculation support

   Firstly, GMPLS per-domain basis path calculation is described. In
   this path calculation model, a GMPLS LSP head-end specifies GMPLS
   domain border nodes as loose hops to tail-end statically or
   dynamically [Path-comp]. The route information may be learned from
   the GMPLS EGP. The source node also calculates the intermediate nodes
   to reach the selected egress domain border node.

   Once the GMPLS path message has traversed to the connecting domain
   border node in the adjacent domain, another path calculation is
   conducted, for example, to expand the ERO carried in the RSVP-TE Path
   message to reach its destination, otherwise to reach an egress border
   node transiting to another domain. This path calculation will not
   necessarily guarantee the domain-to-domain path optimality.

   5.1.2 GMPLS end-to-end basis path calculation support

   GMPLS end-to-end basis path calculation is indicated next. In this
   path calculation, the GMPLS LSP head-end specifies a domain-to-domain
   route (for example, domain1-domain2-domain4-domain5 in Figure 1) as
   well as the intermediate nodes to the egress domain border node in
   its belonging domain. The domain border node in an adjacent domain
   will determine intermediate nodes followed by the specified domain
   path route. This path calculation will guarantee the domain path
   optimality, however, not necessarily guarantee end-to-end path
   optimality.

   5.1.3 Fast Recovery support

   Fast recovery operation based on the end-to-end [e2e] and segment
   [SEG-RECOVERY] based approach should be supported over multiple GMPLS
   domains, considering inter-domain link, SRLG and node diversity.
   These types of operation should interoperate with GMPLS intra-domain
   TE fast recovery mechanism. The domain border node may respond
   indicating a path setup error if it does not support the
   protection/restoration mechanism which is requested by the signaling
   messages generated from the source node in the different domain.

   Depending on the recovery mode, re-optimization or revertive
   operations should be supported.

   5.1.4 Policy Control

   Depending on the policy between domains, the domain border GMPLS
   nodes may reject GMPLS inter-domain signaling messages if the
   unapproved objects are included.

   5.2 Requirement for GMPLS Inter-domain routing for the support of TE


T. Otani et al.   Informational - Expires June 2008           [Page 10]


Internet Drafts  draft-otani-ccamp-interas-gmpls-te-07.txt    Dec. 2007

   In IP/MPLS networks, inter-AS routing such as the EGP is well-defined
   and widely deployed. However, the need for such inter-domain routing
   extension for MPLS TE does not exist at present. Nonetheless, inter-
   domain routing extensions are required to support multiple GMPLS
   domains as well as for layer 1 VPN [L1VPN]. GMPLS extension for
   multi-domain TE is required for guaranteeing inter-domain GMPLS
   constraints, when attempts are made to establish GMPLS LSPs over
   multiple domains as discussed in section 4.

   5.2.1 Reachability information exchange

   GMPLS inter-domain routing mechanism should support the exchange of
   reachability information over each domain. Reachability information
   includes:

        (1) Node ID
        (2) Interface address
        (3) Interface ID

   The reachability information should be advertised in accordance with
   their belonging domain information in order to calculate the GMPLS
   LSP over multiple domains.  The reachability information may be
   aggregated depending on the domain's policy.

   The scalability of inter-domain routing should be considered in
   designing GMPLS extensions to allow exchange of TE information in
   addition to the above reachability information. Furthermore, the
   GMPLS inter-domain routing should be designed to achieve such
   operation that defects in one domain do not affect the scalability of
   an intra-domain routing of IGPs in other domains, although the GMPLS
   inter-domain routing should promptly advertise the failure within the
   domain, ensuring the GMPLS inter-domain connection establishment.

   GMPLS inter-domain routing should basically follow the GMPLS
   architecture [Arch], including the support of its exchange over out
   of band control channel.

   5.2.2 TE parameters exchange

   Coinciding with MPLS Inter-domain work, the TE parameters for GMPLS
   Inter-domain routing are considered to be added.

   A GMPLS domain border node may be required to announce the following
   parameters in association with reachability information of node IDs,
   interface addresses and interface IDs.

   (1) Interface switching capability
        (1-1)Bandwidth
                A. Total link bandwidth
                B. Max./Min. Reservable bandwidth
                C. Maximum LSP bandwidth
                D. minimum LSP Bandwidth
                C. Unreserved bandwidth
        (1-2)Switching capability:  PSC1-4, L2SC, TDM, lambda, LSC, FSC

T. Otani et al.   Informational - Expires June 2008           [Page 11]


Internet Drafts  draft-otani-ccamp-interas-gmpls-te-07.txt    Dec. 2007

   (2) Bandwidth Encoding type: As defined in [RFC3471], e.g., Ethernet,
   SONET/SDH, Lambda.
   (3) SRLG (Global view)
   (4) Protection type

   As mentioned in section 4.4, an end-point (reachability) list
   consisting of node IDs, interface addresses, interface IDs per
   switching capability is formed in order to be advertised over GMPLS
   domains.

   For stitched, nested and contiguous GMPLS LSPs over multiple domains,
   a GMPLS LSP created within a domain will be announced as a (transit)
   link resource (FA-LSP) exposed to different domains with appropriate
   TE parameters, while abstracting intermediate nodes or indicating the
   profile of the TE information. LSP associated information indicating
   available resource may be exchanged as a part of TE routing
   information to support LSP stitching over multiple domains. Such LSP-
   associated information may include a LSP ID and its quality of
   service (QoS) information.

   We may virtually provision logical TE links (virtual TE link) instead
   of such FA-LSPs for these purposes. A Virtual TE link is a new
   concept and will be utilized only to advertise link resources over
   multiple domains.  Operators can create virtual TE links to use some
   of resource in their network only to permit other networks to use it.
   By doing this, the ingress and egress node will become selectable by
   even the source node in other domains.

   The GMPLS inter-domain routing should support these functionalities
   and locally configure this on the domain border nodes.  Moreover, to
   ensure future interworking operation between GMPLS and MPLS, the
   GMPLS inter-domain routing should be also applicable to MPLS inter-
   domain TE information exchange.

   5.2.3 Reachability information redistribution requirement

   GMPLS inter-domain routing must provide redistribution mechanisms
   within the domain in a scalable manner. These information
   redistribution mechanisms must be designed to achieve such operation
   that a defect in a domain does not affect the scalability of intra-
   domain routing in a different domain, although the GMPLS inter-domain
   routing must promptly advertise the failure within the domain,
   ensuring the GMPLS inter-domain connection establishment.

   Mechanisms for redistributing GMPLS TE information within the GMPLS
   domain can be, for example, a path computation element (PCE), I-BGP
   session, or re-injection to IGP. Especially, it is useful to adopt
   GMPLS end-to-end basis path calculation. PCE based requirement may be
   incorporated with the PCE Architecture document [PCE].

   GMPLS inter-domain routing should have the functionality to consider
   any policies for controlling TE routing information to be flooded,
   which will be defined between domains on a business or operational
   strategy basis. GMPLS inter-domain routing policy should be able to

T. Otani et al.   Informational - Expires June 2008           [Page 12]


Internet Drafts  draft-otani-ccamp-interas-gmpls-te-07.txt    Dec. 2007

   be changed and configured on a per domain basis. This policy control
   especially in terms of switching capability may be applicable to the
   extensions of hierarchical routing. Each domain should control the
   advertisement of the switching capability or re-advertisement of
   received switching capability.

   5.2.4 VPN-associated information exchange

   In addition to reachability and TE information exchange, VPN-
   associated information may be exchanged as a part of routing
   information to support L1-VPN functionality, or by other means. VPN-
   associated information may include:

       (1) VPN identifier (such as VPN IP as specified in RFC2685, or
        route target)
       (2) Scope of reachability information exchanged
       (3) VPN membership information
       (4) CE-CE arbitrary control plane communication
       (5) VPN performance related information

   This is exchanged across domains, but may not be injected into other
   domains.

   5.2.5 Inter-link TE information distribution

   In the GMPLS inter-domain network, TE links are configured between
   domain border nodes, however, such TE link information should be
   either flooded by using IGP with TE extension only within each domain
   or by the GMPLS inter-domain routing.

   5.3 GMPLS inter-domain TE Management

   5.3.1 GMPLS inter-domain TE Fault Management

   To maintain the control channel session as well as to provide fault
   isolation mechanism, link management mechanisms such as [LMP] should
   be applied to TE links between GMPLS domain border nodes. To validate
   LSPs created over multiple domains, a generic tunnel tracing protocol
   (GTTP) may be applied [GTTP].

   5.3.2 GMPLS inter-domain TE MIB Requirements

   GMPLS inter-domain TE Management Information Bases must be supported
   to manage and configure GMPLS inter-domain TE in terms of GMPLS LSPs,
   routing, TE links and so forth. These MIBs should extend the existing
   series of MIBs [GMPLS-TEMIB] to accommodate following
   functionalities;

   - To manage GMPLS LSP characteristics at the tunnel head-end as well
    as any other points of the TE tunnel.
   - To include both IPv4/v6 and domain identifier, or only domain
    identifier in the subobjects of GMPLS RSVP ERO. A label may be
    included in it.  The example of the object is as follows;


T. Otani et al.   Informational - Expires June 2008           [Page 13]


Internet Drafts  draft-otani-ccamp-interas-gmpls-te-07.txt    Dec. 2007

    EXPLICIT_ROUTE class object:
    Address1 (loose IPv4 address prefix,label, /domain1)
    Address2 (loose IPv4 address prefix,label, /domain1)
    domain2  (domain number)
    Address3 (loose IPv4 address prefix,label, /domain3)
    Address4 (loose IPv4 address prefix,label, /domain3)-destination

    Or

    Address1 (loose IPv4 address prefix,label, /domain1)
    Address2 (loose IPv4 address prefix,label, /domain1)
    Address3 (loose IPv4 address prefix,label, /domain2)
    Address4 (loose IPv4 address prefix,label, /domain2)
    Address5 (loose IPv4 address prefix,label, /domain3)
    Address6 (loose IPv4 address prefix,label, /domain3)-destination

   - Inclusion of recording subobjects such as interface IPv4/v6
    addresses, domain identifier, a label, a node-id and so on in the
    RRO of the RESV message, considering the established policies
    between GMPLS domains.


6. Security consideration

   GMPLS inter-domain TE should be implemented under a certain security
   consideration such as authentication of signaling and routing on the
   control plane as well as a data plane itself.  Indeed, this will not
   change the underlying security issues.


7. Acknowledgement

   The author would like to express the thanks to Noaki Yamanaka, Kohei
   Shiomoto, Michiaki Hayashi, Zafar Ali, Adrian Farrel, Tomonori Takeda,
   Igor Bryskin, John Drake and Kenji Kumaki for their comments.


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

T. Otani et al.   Informational - Expires June 2008           [Page 14]


Internet Drafts  draft-otani-ccamp-interas-gmpls-te-07.txt    Dec. 2007


   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.


9. Informative references
  [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.
  [Inter-domain]  A. Farrel, et al, "A framework for inter-domain MPLS
                  traffic engineering", RFC4726, November 2006.
  [MPLS-AS]      R. Zhan, et al, "MPLS Inter-Autonomous System (AS)
                  Traffic Engineering (TE) Requirements", RFC4216,
                  November 2005.
  [LMP]          J. P. Lang, et al, "Link Management Protocol (LMP)",
                  RFC4204, October 2005.
  [GMPLS-Routing] K. Kompella, et al, "Routing Extensions in Support of
                  Generalized Multi-Protocol Label Switching", RFC4202,
                  October 2005.
  [L1VPN]        T. Takeda, et al, "Framework and Requirements for
                  Layer 1 Virtual Private Networks", RFC4847, April,
                  2007.
  [PCE]          A. Farrel, et al, "A Path Computation Element (PCE)-
                  Based Architecture", RFC4655, August 2006.
  [Arch]         E. Mannie, et al, "Generalized Multi-Protocol Label
                  Switching Architecture", RFC3945, October, 2004.
  [Path-comp]    J. P. Vasseur, et al, "A Per-domain path computation
                  method for establishing Inter-domain Traffic
                  Engineering (TE) Label Switched Paths (LSPs)", draft-
                  ietf-ccamp-inter-domain-pd-path-comp-06, Nov., 2007.
  [GMPLS-ROUTING] K. Kompella, et al, "Routing Extensions in Support of
                  Generalized Multi-Protocol Label Switching", RFC4203,
                  Oct. 2005.
  [e2e]          J.P. Lang, Ed., "RSVP-TE Extensions in Support of
                  End-to-End Generalized Multi-Protocol Label Switching
                  (GMPLS) Recovery", RFC4872, May 2007.
  [SEG-RECOVERY]  L. Berger, et al, "GMPLS Segment Recovery", RFC4873,
                  May 2007.
  [GTTP]         R. Bonica, et al, "Generic Tunnel Tracing Protocol
                  (GTTP) Specification", draft-ietf-ccamp-tunproto-
                  01.txt, Sept. 2004.
  [GMPLS-TEMIB]   T. Nadeau and A. Farrel, Ed., "Generalized
                  Multiprotocol Label Switching (GMPLS) Traffic
                  Engineering Management Information Base", RFC4802,
                  Feb. 2007.


Author's Addresses

   Tomohiro Otani
   KDDI R&D Laboratories, Inc.
   2-1-15 Ohara Kamifukuoka Saitama, 356-8502. Japan

T. Otani et al.   Informational - Expires June 2008           [Page 15]


Internet Drafts  draft-otani-ccamp-interas-gmpls-te-07.txt    Dec. 2007

   Phone:  +81-49-278-7357
   Email:  otani@kddilabs.jp

   Shuichi Okamoto
   KDDI R&D Laboratories, Inc.
   2-1-15 Ohara Kamifukuoka Saitama, 356-8502. Japan
   Phone:  +81-49-278-7837
   Email:  okamoto@kddilabs.jp

   Satoru Okamoto
   Keio University
   3-14-1 Hiyoshi Kohoku-ku Yokohama, Kanagawa 223-8552. Japan
   Phone: +81-45-563-1151
   Email: okamoto@ieee.org

   Wataru Imajuku
   NTT Network Innovation Laboratories
   Phone: +81-46-859-4315
   Email: imajuku.wataru@lab.ntt.co.jp


Document expiration

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


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.   Informational - Expires June 2008           [Page 16]


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