INTERNET-DRAFT T. Otani
Intended status: Informational K. Ogaki
Expires:August 2008 KDDI R&D Labs
Feb. 18, 2008
Requirements for GMPLS applications of PCE
Document: draft-otani-pce-gmpls-aps-req-00.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
The initial effort of PCE WG is specifically focused on MPLS (Multi-
protocol label switching). As a next step, this draft describes
functional requirements for GMPLS (Generalized MPLS) application of
PCE (Path computation element).
Table of Contents
Status of this Memo................................................ 1
Abstract........................................................... 1
1. Introduction.................................................... 3
2. Conventions used in this document............................... 3
3. GMPLS applications of PCE....................................... 3
4. Requirement for GMPLS application of PCE........................ 4
5. Security consideration.......................................... 5
6. Acknowledgement................................................. 5
7. Intellectual property considerations............................ 5
T. Otani et al. Informational - Expires Aug. 2008 [Page 1]
Internet Drafts draft-otani-pce-GMPLS-req-00.txt Feb. 2008
8. Informative references.......................................... 6
Author's Addresses................................................. 7
Document expiration................................................ 7
Copyright statement................................................ 7
T. Otani et al. Informational - Expires August 2008 [Page 2]
Internet Drafts draft-otani-pce-GMPLS-req-00.txt Feb. 2008
1. Introduction
The initial effort of PCE WG is focused on solving the path
computation problem over domains in MPLS networks. As the same case
with MPLS, service providers (SPs) have also come up with
requirements for path computation in GMPLS networks such as TDM-based
or Ethernet-based networks as well.
[PCE-ARCH] and [PCECP-REQ] discuss the framework and requirements for
PCE on both packet MPLS networks and (non-packet switch capable)
GMPLS networks. This document complements these documents by
providing some consideration of GMPLS applications in multi-domain
networking environment and indicating a set of requirements for the
extended definition of series of PCE related protocols.
Constrained baaed shortest path first (CSPF) computation within a
domain or over domains for signaling GMPLS Label Switched Paths
(LSPs) is more stringent than that of MPLS LSPs [MPLS-AS], because
the additional constraints, e.g., interface switching capability,
link encoding, link protection capability and so forth need to be
considered to establish GMPLS LSPs [CSPF]. GMPLS signaling protocol
[RFC3471, RFC3473] is designed taking 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, appropriately.
This document provides the investigated results of GMPLS applications
of PCE especially for the support of GMPLS inter-domain path
computation. This document also outlines GMPLS inter-domain
architecture, and provides requirements for GMPLS applications of PCE
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].
3. GMPLS applications of PCE
3.1 GMPLS 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|----------+
| +----+----+ |
T. Otani et al. Informational - Expires August 2008 [Page 3]
Internet Drafts draft-otani-pce-GMPLS-req-00.txt Feb. 2008
+----+----+ | +----+----+ +---------+
|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 manages traffic engineering
database (TED) by PCE, and exchanges or provides route information of
paths, while concealing its internal topology information.
3.2 Path computation in GMPLS network
[CSPF] describes consideration of GMPLS TE attributes during path
computation.
Ingress Transit Egress
+-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+
|Node1|------------>|Node2|------------>|Node3|------------>|Node4|
| |<------------| |<------------| |<------------| |
+-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+
Figure 2: Path computation in GMPLS networks.
For the simplicity 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.
[CSPF] indicates the possible table of switching capability, encoding
type and bandwidth at the ingress link, transiting links and the
egress link which need to be satisfied with the created LSP.
4. Requirement for GMPLS application of PCE
In this section, we describe requirements for GMPLS applications for
PCE in order to establish GMPLS LSP over domains.
T. Otani et al. Informational - Expires August 2008 [Page 4]
Internet Drafts draft-otani-pce-GMPLS-req-00.txt Feb. 2008
4.1 PCE requirements
Considering path computation in GMPLS networks in section 3, a PCE
needs to consider the GMPLS TE attributes appropriately according to
tables in [cspf] according to the request from a PCC. As a result,
the path calculation request message from PCC needs to contain the
information specifying appropriate attributes. Additional attributes
to those already defined in [PCECP] are as follows.
(1) Switching capability: PSC1-4, L2SC, TDM, lambda, LSC, FSC
(2) Bandwidth Encoding type: as defined in [RFC3471], e.g., Ethernet,
SONET/SDH, Lambda, etc.
(3) Path protection type: as defined in [Protection], e.g., 1+1
protection, dynamic path, etc.
4.2 PCC requirements
As described above, a PCC needs to support to initiate path
computation request specifying abovementioned attributes. Afterwards,
GMPLS signaling will be invoked according to the responded messages
from the PCE.
4.3 GMPLS PCE Management
PCE related Management Information Bases need to consider extensions
to be satisfied with requirements for GMPLS applications. For
extensions, [GMPLS-TEMIB] are defined to manage TE database and may
be referred to accommodate GMPLS TE attributes in the PCE.
5. Security consideration
PCE extensions to support GMPLS should be considered under the same
security as current work. This extension will not change the
underlying security issues.
6. Acknowledgement
The author would like to express the thanks to S. Okamoto for his
comments.
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
T. Otani et al. Informational - Expires August 2008 [Page 5]
Internet Drafts draft-otani-pce-GMPLS-req-00.txt Feb. 2008
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. Informative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PCE-ARCH] A. Farrel, et al, "A Path Computation Element (PCE)-
Based Architecture", RFC4655, Aug., 2006.
[PCECP-REQ] J. Ash, et al, "Path computation element (PCE)
communication protocol generic requirements", RFC4657,
Sept., 2007.
[Protection] J.P. Lang, Ed., "RSVP-TE Extensions in Support of
End-to-End Generalized Multi-Protocol Label Switching
(GMPLS) Recovery", RFC4872, May 2007.
[MPLS-AS] R. Zhan, et al, "MPLS Inter-Autonomous System (AS)
Traffic Engineering (TE) Requirements", RFC4216,
November 2005.
[CSPF] T. Otani, et al, "Considering Generalized
Multiprotocol Label Switching Traffic Engineering
Attributes During Path Computation", draft-otani-
ccamp-gmpls-cspf-constraints-07.txt, Nov., 2007.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label
Switching (MPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (MPLS) Signaling - Resource ReserVation
Protocol Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[Inter-domain] A. Farrel, et al, "A framework for inter-domain MPLS
traffic engineering", RFC4726, November 2006.
[Arch] E. Mannie, et al, "Generalized Multi-Protocol Label
Switching Architecture", RFC3945, October, 2004.
[PCECP] JP. Vasseur, et al, "Path Computation Element (PCE)
Communication Protocol (PCEP)", draft-ietf-pce-pcep-
10.txt, Feb., 2008.
[GMPLS-TEMIB] T. Nadeau and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Traffic
Engineering Management Information Base", RFC4802,
Feb. 2007.
T. Otani et al. Informational - Expires August 2008 [Page 6]
Internet Drafts draft-otani-pce-GMPLS-req-00.txt Feb. 2008
Author's Addresses
Tomohiro Otani
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Kamifukuoka Saitama, 356-8502. Japan
Phone: +81-49-278-7357
Email: otani@kddilabs.jp
Kenichi Ogaki
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Kamifukuoka Saitama, 356-8502. Japan
Phone: +81-49-278-7897
Email: ogaki@kddilabs.jp
Document expiration
This document will be expired in August 31, 2008, unless it is
updated.
Copyright statement
Copyright (C) The IETF Trust (2008).
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 August 2008 [Page 7]