One document matched: draft-otani-ccamp-gmpls-routing-interlink-01.txt
Differences from draft-otani-ccamp-gmpls-routing-interlink-00.txt
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] | PAFTECH AB 2003-2026 | 2026-04-23 17:12:38 |