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

Versions: 00 01

INTERNET-DRAFT                                                 T. Otani
Intended status: Informational                                 K. Ogaki
Expires:May, 2008                                            S. Okamoto
                                                          KDDI R&D Labs
                                                      November 14, 2007


        GMPLS Inter-Domain Routing in support of inter-domain links

        Document: draft-otani-ccamp-gmpls-routing-interlink-01.txt



Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.


Abstract

   This draft states the problem of the current generalized multi-
   protocol label switching (GMPLS) routing in order to deal with inter-
   domain TE links for GMPLS inter-domain signaling. Since the GMPLS
   signaling protocol introduces bi-directional label switched path
   (LSP) creation mechanism, an ingress node (or a path computation
   element) searches for the bidirectional route in the traffic
   engineering database (TED). Considering the GMPLS inter-domain path
   creation, the TED contains only outgoing TE information of inter-
   domain links and will not be able to confirm the validity of the
   incoming inter-domain links.  In order to solve this issue, we
   describe the GMPLS inter-domain routing requirement in support of
   exchanging of inter-domain TE link information.


Table of Contents

   Status of this Memo................................................ 1

T. Otani et al.    Informational - Expires May 2007            [Page 1]


Internet Drafts                                               Nov. 2007

   Abstract........................................................... 1
   1. Introduction.................................................... 3
   2. Conventions used in this document............................... 3
   3. GMPLS inter-domain path establishment........................... 3
   4. GMPLS inter-domain routing requirements in support of inter-domain
   TE link information................................................ 4
   5. Security consideration.......................................... 5
   6. Acknowledgement................................................. 5
   7. Intellectual property considerations............................ 5
   8. References...................................................... 5
   Author's Addresses................................................. 6
   Document expiration................................................ 7
   Copyright statement................................................ 7

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


Internet Drafts                                               Nov. 2007

1. Introduction

   A framework for establishing and controlling Multiprotocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE)
   Label Switched Paths (LSPs) in multi-domain networks has been defined
   so far [RFC4726], and enabling protocols and mechanisms are
   intensively investigated [ID-RSVP-TE, ID-PD-PATHCOMP, RFC4655, INTER-
   AS-OSPF]. Those mainly focus on MPLS inter-domain networks while
   toughing upon the applicability to GMPLS. However, since LSP
   directionality is differing between MPLS and GMPLS, this would be a
   stringent constrain in the case of inter-domain GMPLS LSP creation.

   Therefore, this document states the problem of the current
   generalized multi-protocol label switching (GMPLS) routing in order
   to deal with inter-domain TE links in the case of GMPLS inter-domain
   path creation. Since the GMPLS signaling protocol enables bi-
   directional label switched path (LSP) creation, an ingress node (or a
   path computation element) searches for the bidirectional route in the
   traffic engineering database (TED). In the case of the GMPLS inter-
   domain path creation, the ingress node searches the bi-directional
   route according to [ID-PD-PATHCOMP]. The TED contains only outgoing
   TE information of inter-domain links originating from the own domain
   border node, which might be statically and locally configured, and
   the ingress node cannot confirm the validity of incoming inter-domain
   TE links from the domain boarder node in the adjacent domain. Thus,
   an appropriate mechanism is required to support the information
   exchange of inter-domain links with TE extensions.


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. GMPLS inter-domain path establishment

   3.1 Assumed network model

                                    |
                                   |
  +-------+          +-------+     |     +-------+          +-------+
  |       |          |       |  IDL-out  |       |          |       |
  |       |----//--->|Domain |---------->|Domain |----//----|       |
  |Ingress|          |Border |           |Border |          |Egress |
  |       |          |Node 1 |  IDL-in   |Node 2 |          |       |
  |       |<---//----|       |<----------|       |<---//----|       |
  |       |          |       |     |     |       |          |       |
  +-------+          +-------+     |     +-------+          +-------+
                                   |
          GMPLS domain 1           |          GMPLS domain 2



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


Internet Drafts                                               Nov. 2007

                Figure 1: GMPLS inter-domain network model

   Figure 1 indicates the assumed GMPLS inter-domain network model. Here,
   we assume a very simple GMPLS inter-domain network model consisting
   of two GMPLS domains (domain 1 and domain 2). Each domain border node
   is connected by an inter-domain link (IDL). An interior gateway
   protocol (IGP) with TE extensions such as OSPF-TE or ISIS-TE [RFC4202,
   RFC4203, RFC4205] is responsible for distributing the routing
   information with TE. Between domains, an exterior gateway protocol
   (EGP) such as BGP-4 or static route configuration may be applied to
   exchange the reachability information and domain-to-domain routes.
   The ingress node either calculates the path in its own domain or asks
   the route to a PCE for GMPLS inter-domain signaling.


   3.2 Path computation

   Nodes in each GMPLS domain exchange the routing information with TE
   extensions by the IGP. The IGP can also distribute the routing
   information of IDL-out within GMPLS domain 1 by [INTER-AS-OSPF,
   INTER-AS-ISIS], but not to GMPLS domain 2 because of the domain
   boundary. This IDL-out is statistically and locally configured.
   Furthermore, GMPLS attributes are additionally to be supported to the
   OSPF-TE object in [INTER-AS-OSPF].

   Even if the domain border node 2 may notify only reachability
   information of GMPLS domain 2 including itself to the domain border
   node 1 by a dynamic way, the TED of the Ingress node in GMPLS domain
   1 does not contain the TE information of the IDL-in Link. This is
   because currently defined protocol mechanisms do not support dynamic
   way to exchange inter-domain TE links between domain border nodes.

   In the case of MPLS path creation, since the path is uni-directional,
   the TE information of the IDL-out link in the TED is sufficient for
   the ingress node. On the contrary, in the case of GMPLS, the ingress
   node will not calculate the bi-directional route to the domain border
   node 2 by using the TED, unless the TE information of the IDL-in link
   is also statically and manually configured.  Moreover, if a failure
   occurs over the IDL-in link, the Ingress node may not know it because
   of the luck of the mechanism. Therefore, GMPLS routing mechanism is
   desired to be in support of exchanging of inter-domain TE link
   information for GMPLS inter-domain path establishment.


4. GMPLS inter-domain routing requirements in support of inter-domain TE
link information

   In order to solve the abovementioned issue, we describe the GMPLS
   inter-domain routing requirements.

   In addition to outgoing inter-domain links with MPLS TE information
   [INTER-AS-OSPF], incoming inter-domain links with TE information
   should be distributed to the own domain in support of appropriate
   GMPLS attributes such as a switching capability and an encoding type.

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


Internet Drafts                                               Nov. 2007

   Consequently, the TED in each domain should be appropriately created
   so as to contain inter-domain TE links. The TED may be synchronized
   with the database in the PCE.

   The incoming inter-domain link, as the same with outgoing inter-
   domain TE links, can be statistically and locally configured.
   However, ideally speaking, dynamically exchanging mechanism would be
   preferred reflecting aliveness of adjacent inter-domain border nodes.


5. Security consideration

   GMPLS inter-domain routing to advertise additionally incoming inter-
   domain links with TE information will not change the underlying
   security issues of GMPLS networks.


6. Acknowledgement

   The author would like to express the thanks to Adrian Farrel for the
   discussion.


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.


8. References
8.1 Informative references

  [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

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


Internet Drafts                                               Nov. 2007

  [RFC4726]      A. Farrel, et al, "A framework for inter-domain MPLS
                  traffic engineering", draft-ietf-ccamp-inter-domain-
                  framework-01.txt, February 2005.
  [RFC4655]      Farrel, et al, "A Path Computation Element (PCE)-
                  Based Architecture", RFC 4655, August 2006.
  [RFC4202]      K. Kompella, et al, "Routing Extensions in Support of
                  Generalized Multi-Protocol Label Switching", RFC4202,
                  October 2005.
  [RFC4203]      K. Kompella, et al, "OSPF Extensions in Support of
                  Generalized Multi-Protocol Label Switching (GMPLS)",
                  RFC4203, October 2005.
  [RFC4205]      K. Kompella, et al, "Intermediate System to
                  Intermediate System (IS-IS) Extensions in Support of
                  Generalized Multi-Protocol Label Switching (GMPLS)",
                  RFC4205, October 2005.

8.2 Informative references

  [ID-RSVP-TE]   A. Farrel, et al, "Inter domain MPLS and GMPLS
                  Traffic Engineering - RSVP-TE extensions", draft-
                  ietf-ccamp-inter-domain-rsvp-te-07.txt, January 2007.
  [ID-PD-PATHCOMP]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-04, Jan 2007.
  [INTER-AS-OSPF] M. Chen, et al, "OSPF Traffic Engineering (OSPF-TE)
                  extensions in support of inter-AS multiprotocol label
                  switching (MPLS) and generalized MPLS (GMPLS) traffic
                  engineering", draft-ietf-ccamp-ospf-interas-te-
                  extension-01.txt, Sept. 6, 2007.


Author's Addresses

   Tomohiro Otani
   KDDI R&D Laboratories, Inc.
   2-1-15 Ohara Fujimino
   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
   Saitama, 356-8502. Japan
   Phone:  +81-49-278-7897
   Email:  ogaki@kddilabs.jp

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

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


Internet Drafts                                               Nov. 2007


Document expiration

   This document will be expired in Sept. 30, 2007, 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 May 2008            [Page 7]


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