Network Working Group Tomohiro Otani
Internet Draft KDDI
Intended status: Informational Kenichi Ogaki
KDDI R&D Labs
Diego Caviglia
Ericsson
Fatai Zhang
Huawei
Expires: November 30, 2011 May 30,2011
Requirements for GMPLS applications of PCE
Document: draft-ietf-pce-gmpls-aps-req-04.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and 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.
This Internet-Draft will expire on November 30, 2011.
Abstract
The initial effort of PCE WG is specifically focused on MPLS (Multi-
protocol label switching). As a next step, this draft describes
T. Otani et al. Expires November 2011 [Page 1]
Internet Draft Reqs for GMPLS apps of PCE May 2011
functional requirements for GMPLS (Generalized MPLS) application of
PCE (Path computation element).
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 [RFC2119].
Table of Contents
1. Introduction ................................................ 2
2. Terminology ................................................. 3
3. GMPLS applications of PCE.................................... 3
3.1. GMPLS network model..................................... 3
3.2. Path computation in GMPLS network .......................4
3.3. Unnumbered Interface.................................... 6
3.4. Asymmetric Bandwidth Path Computation ...................6
4. Requirements for GMPLS applications of PCE ...................6
4.1. Requirements of Path Computation Request ................6
4.2. Requirements of Path Computation Reply ..................7
4.3. GMPLS PCE Management.................................... 8
5. Security consideration....................................... 8
6. IANA Considerations ......................................... 9
7. Acknowledgement ............................................. 9
8. References .................................................. 9
9. Authors' Addresses ......................................... 11
1. Introduction
The initial effort of PCE WG is focused on solving the path
computation problem over different 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 photonics,
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 considerations of GMPLS applications in the intra-
domain and inter-domain networking environments and indicating a set
of requirements for the extended definition of series of PCE related
protocols.
Note that the requirements for inter-layer traffic engineering
described in [PCE-INTER LAYER-REQ] are outside of the scope of this
document.
T. Otani et al. Expires November 2011 [Page 2]
Internet Draft Reqs for GMPLS apps of PCE May 2011
Constraint based 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 type, encoding type, SRLG, and protection attributes of the
TE links spanned by the path, as well as LSP encoding and switching
type for the end points, appropriately.
This document provides the investigated results of GMPLS applications
of PCE for the support of GMPLS path computation. This document also
provides requirements for GMPLS applications of PCE in the GMPLS
intra-domain and inter-domain environments.
2. Terminology
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 [RFC2119].
3. GMPLS applications of PCE
3.1. GMPLS network model
Figure 1 depicts a typical network, consisting of several
GMPLSdomains, assumed in this document. D1, D2, D3 and D4 have
multiple GMPLS inter-domain connections, while D5 has only one GMPLS
inter-domain connection. These domains follow the definition in
[RFC4726].
+---------+
+---------|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 switching capability, encoding type,
etc., making the problem a bit different from the case of classical
T. Otani et al. Expires November 2011 [Page 3]
Internet Draft Reqs for GMPLS apps of PCE May 2011
(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. Figure 2 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.
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 consideration, the below basic assumptions are
made when the LSP is created.
(1) Switching capabilities of outgoing links from the ingress and
egress nodes (link1-2 and link4-3 in Figure 2) must be consistent
with each other.
(2) Switching capabilities 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 tables of switching capability,
encoding type and bandwidth at the ingress link, transiting links and
the egress link which need to be satisfied with GMPLS path
computation of the created LSP.
The non-packet GMPLS networks (e.g., TDM networks) are usually
responsible for transmitting data for the client layer. These GMPLS
networks can provide different types of connections for customer
services based on different service bandwidth requests.
T. Otani et al. Expires November 2011 [Page 4]
Internet Draft Reqs for GMPLS apps of PCE May 2011
The applications and the corresponding additional requirements for
applying PCE in non-packet networks, for example, GMPLS-based TDM
networks, are described in Figure 3. In order to simplify the
description, this document just discusses the scenario in SDH
networks as an example. The scenarios in SONET or G.709 ODUk layer
networks are similar.
N1 N2
+-----+ +------+ +------+
| |-------| |--------------| | +-------+
+-----+ | |---| | | | |
A1 +------+ | +------+ | |
| | | +-------+
| | | PCE
| | |
| +------+ |
| | | |
| | |-----| |
| +------+ | |
| N5 | |
| | |
+------+ +------+
| | | | +-----+
| |--------------| |--------| |
+------+ +------+ +-----+
N3 N4 A2
Figure 3: A simple SDH network
Figure 3 shows a simple network topology, where N1, N2, N3, N4 and N5
are all SDH switches. Assume that one Ethernet service with 100M
bandwidth is required from A1 to A2 over this network. The client
Ethernet service could be provided by a VC4 connection from N1 to N4,
and it could also be provided by three concatenated VC3 connections
(Contiguous or Virtual concatenation) from N1 to N4.
The type of connection(s) (one VC4 or three concatenated VC3) that is
required needs to be specified by PCC (e.g., N1 or NMS), but could
also be determined by PCE automatically based on policy [RFC5394].
Therefore, the signal type, the type of the concatenation and the
number of the concatenation should also be considered during path
computation for PCE.
T. Otani et al. Expires November 2011 [Page 5]
Internet Draft Reqs for GMPLS apps of PCE May 2011
3.3. Unnumbered Interfaces
GMPLS support unnumbered interface ID that is defined in [RFC 3477],
which means that the endpoints of the path may be unnumbered. It
should also be possible to request a path between a numbered link and
an unnumbered link, or a P2MP path between different types of
endpoints. Therefore, the PCC should be capable of indicating the
unnumbered interface ID of the endpoints in the PCReq message.
3.4. Asymmetric Bandwidth Path Computation
As per [RFC 5467], GMPLS signaling can be used for setting up an
asymmetric bandwidth bidirectional LSP. If a PCE is responsible for
the path computation, the PCE should be capable of computing a path
for the bidirectional LSP with asymmetric bandwidth. It means that
the PCC should be able to indicate the asymmetric bandwidth
requirements in forward and reverse directions in the PCReq message.
4. Requirements for GMPLS application of PCE
In this section, we describe requirements for GMPLS applications of
PCE in order to establish GMPLS LSP.
4.1. Requirements of Path Computation Request
As for path computation in GMPLS networks as discussed in section 3,
the PCE needs to consider the GMPLS TE attributes appropriately
according to tables in [CSPF] once a PCC or another PCE requests a
path computation. Indeed, the path calculation request message from
the PCC or the PCE needs to contain the information specifying
appropriate attributes. According to [RFC5440],[PCEP-EXT],[ PCE-WSON-
REQ] and to RSVP procedures like explicit label control(ELC),the
additional attributes introduced are as follows: [RFC5440]
(1) Switching capability: PSC1-4, L2SC, DCSC [DCSC-Ext], 802_1 PBB-TE
[GMPLS-PBB-TE], TDM, LSC, FSC
(2) Encoding type: as defined in [RFC4202], [RFC4203], e.g., Ethernet,
SONET/SDH, Lambda, etc.
(3) Signal Type: Indicates the type of elementary signal that
constitutes the requested LSP. A lot of signal types with
different granularity have been defined in SONET/SDH and G.709 ODUk,
such as VC11, VC12, VC2, VC3 and VC4 in SDH, and ODU1, ODU2 and ODU3
in G.709 ODUk. See[RFC4606] , [RFC4328]and [OSPF-G709] or [RSVP-TE-
G709].
T. Otani et al. Expires November 2011 [Page 6]
Internet Draft Reqs for GMPLS apps of PCE May 2011
(4) Concatenation Type: In SDH/SONET and G.709 ODUk networks, two
kinds of concatenation modes are defined: contiguous
concatenation which requires co-route for each member signal and
requires all the interfaces along the path to support this capability,
and virtual concatenation which allows diverse routes for the member
signals and only requires the ingress and egress interfaces to
support this capability. Note that for the virtual concatenation, it
also may specify co-routed or separated-routed. See [RFC4606] and
[RFC4328] about concatenation information.
(5) Concatenation Number: Indicates the number of signals that are
requested to be contiguously or virtually concatenated. Also see
[RFC4606] and [RFC4328].
(6) Technology specific label(s) such as wavelength label as defined
in [RFC6205].
(7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1
protection, 1:1 protection, (pre-planned) rerouting, etc.
(8) Administrative group: as defined in [RFC3630].
(9) Link Protection type: as defined in [RFC4203].
(10)Support for unnumbered interfaces: as defined in [RFC3477].
(11)Support for asymmetric bandwidth request: as defined in [RFC
5467].
(12)Support for explicit label control during the path computation.
4.2. Requirements of Path Computation Reply
As described above, a PCC needs to support to initiate a PCReq
message specifying above mentioned attributes. The PCE needs to
compute the path that satisfies the constraints which are specified
in the PCReq message. Then the PCE needs to send a PCRep message
including the computation result to the PCC. For Path Computation
Reply message (PCRep) in GMPLS networks, there are some additional
requirements. The PCEP PCRep message needs to be extended to meet the
following requirements.
(1) Concatenation path computation
In the case of concatenation path computation, when a PCE receives
the PCReq message specifying the concatenation constraints described
T. Otani et al. Expires November 2011 [Page 7]
Internet Draft Reqs for GMPLS apps of PCE May 2011
in section 4.1, the PCE should compute the path which satisfies the
specified concatenation constraints.
For contiguous concatenation path computation, the routes of each
member signal must be co-routed and all the interfaces along the
route should support contiguous concatenation capability. Therefore,
the PCE needs to compute a path based on the contiguous concatenation
capability of each interface and only one ERO which carries the route
information is needed for the response.
For virtual concatenation path computation, only the ingress/egress
interfaces need to support virtual concatenation capability and maybe
there are diverse routes for the different member signals. Therefore,
multiple EROs may be needed for the response. Each ERO may represent
the route of one or multiple member signals. In the case that one ERO
represents several member signals among the total member signals, the
number of member signals along the route of the ERO needs to be
specified.
(2) Wavelength label
In the case that a PCC doesn't specify the wavelength when requesting
a wavelength path and the PCE is capable of performing the route and
wavelength computation procedure, the PCE needs to be able to specify
the wavelength of the path in a PCRep message.
(3) Roles of the routes
When a PCC specifies the protection type of the LSPs, the PCE needs
to compute the working route and the corresponding protection
route(s). Therefore, the PCRep should be capable of indicate which
one is working or protection route.
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.
T. Otani et al. Expires November 2011 [Page 8]
Internet Draft Reqs for GMPLS apps of PCE May 2011
6. IANA Considerations
This document has no actions for IANA.
7. Acknowledgement
The author would like to express the thanks to Shuichi Okamoto for
his comments.
8. 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.
[PCE-INTER LAYER-REQ] T.Takeda,et al,"PCC-PCE Communication and PCE
Discovery Requirements for Inter-Layer
Engineering",December 2010.
[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, Feb., 2008.
[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.
[RFC4726] 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.
T. Otani et al. Expires November 2011 [Page 9]
Internet Draft Reqs for GMPLS apps of PCE May 2011
[RFC5394] I.Bryskin,et al,"Policy-Enabled Path Computation
Framework",RFC5394,December 2008.
[RFC3477] K.Kompella,et al,"Signalling Unnumbered Links in Resource
ReSerVation Protocol-Traffic Engineering(RSVP-
TE)",January 2003.
[RFC5476] B.Claise,Ed,"Packet Sampling(PSAMP) Protocol
Specifications",March 2009.
[RFC5440] J.P. Vasseur, et al, "Path Computation Element (PCE)
Communication Protocol (PCEP)", RFC5440, March 2009.
[PCEP-EXT] C.Margaria,et al, "PCEP extensions for GMPLS",draft-
ietf-pce-gmpls-PCEP-EXTs-02.txt,March 2011.
[PCE-WSON-REQ] Y.Lee, et al,"PCEP Requirements for WSON Routing and
Wavelength Assignment",draft-ietf-pce-wson-routing-
wavelength-04.txt,March 2011.
[RFC4202] K. Kompella, and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching",
RFC4202, Oct. 2005.
[RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching", RFC4203,
Oct. 2005.
[RFC4872] J.P. Lang, Ed., "RSVP-TE Extensions in Support of End-to-
End Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC4872, May 2007.
[GMPLS-TEMIB] T. Nadeau and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Traffic Engineering
Management Information Base", RFC4802, Feb. 2007.
[RFC3630] D. Katz et al., "Traffic Engineering (TE) Extensions to
OSPF Version 2", RFC3630, September 2003.
[Lambda-label] T. Otani, Ed., "Generalized Labels for G.694 Lambda-
Switching Capable Label Switching Routers", draft-ietf-
ccamp-gmpls-g-694-lambda-labels, in progress.
[RFC5394] I. Bryskin et al., " Policy-Enabled Path Computation
Framework", RFC5394, December 2008.
T. Otani et al. Expires November 2011 [Page 10]
Internet Draft Reqs for GMPLS apps of PCE May 2011
[RFC4606] E. Mannie and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC4606, August 2006.
[RFC4328] D. Papadimitriou, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC4328, January 2006.
[RFC3477] K.Kompella,"Signalling Unnumbered Links in Resource
ReServation Protocol-Traffic Engineering(RSVP-
TE)",January 2003.
[OSPF-G709] D.Ceccarelli,et al,"Traffic Engineering Extensions to
OSPF for Generalized MPLS(GMPLS) Control of Evolving
G.709 OTN Networks",March 2011.
[RSVP-TE-G709] Fatai Zhang,et al,"Generalized Multi-Protocol Label
Switching(GMPLS) Signaling Extensions for the evolving
G.709 Optical Transport Network Control",March 2011.
[DCSC-Ext] Lou Berger, et al.,"Generalized MPLS (GMPLS) Data Channel
Switching Capable (DCSC) and Channel Set Label
Extensions", in progress.
[GMPLS-PBB-TE] Don Fedyk, et al., "Generalized Multiprotocol Label
Switching (GMPLS) control of Ethernet PBB-TE", in
progress.
9. Authors' Addresses
Tomohiro Otani
KDDI Corporation
2-3-2 Nishi-shinjuku Shinjuku-ku, Tokyo 163-8003 Japan
Phone: +81-3-3347-6006
Email: tm-otani@kddi.com
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
Diego Caviglia
Ericsson
16153 Genova Cornigliano, ITALY
T. Otani et al. Expires November 2011 [Page 11]
Internet Draft Reqs for GMPLS apps of PCE May 2011
Phone: +390106003736
Email: diego.caviglia@ericsson.com
Fatai Zhang
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Intellectual Property
The IETF Trust 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 any IETF 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.
Copies of Intellectual Property 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
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
T. Otani et al. Expires November 2011 [Page 12]
Internet Draft Reqs for GMPLS apps of PCE May 2011
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
T. Otani et al. Expires November 2011 [Page 13]
