draft-ietf-pce-gmpls-aps-req-08.txt   draft-ietf-pce-gmpls-aps-req-09.txt 
Network Working Group T. Otani Network Working Group T. Otani
Internet-Draft K. Ogaki Internet-Draft K. Ogaki
Intended status: Informational KDDI Intended status: Informational KDDI
Expires: December 12, 2013 D. Caviglia Expires: January 22, 2014 D. Caviglia
Ericsson Ericsson
F. Zhang F. Zhang
Huawei Technologies Huawei Technologies
C. Margaria C. Margaria
Coriant R&D GmbH Coriant R&D GmbH
June 10, 2013 July 21, 2013
Requirements for GMPLS applications of PCE Requirements for GMPLS applications of PCE
draft-ietf-pce-gmpls-aps-req-08.txt draft-ietf-pce-gmpls-aps-req-09.txt
Abstract Abstract
The initial effort of the PCE (Path computation element) WG is The initial effort of the PCE (Path computation element) WG was
specifically focused on MPLS. As a next step, this draft describes mainly focused on MPLS. As a next step, this draft describes
functional requirements for GMPLS application of PCE. functional requirements for GMPLS application of PCE.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 12, 2013. This Internet-Draft will expire on January 22, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The initial effort of the PCE (Path computation element) WG is The initial effort of the PCE (Path computation element) WG was
focused on solving the path computation problem within a domain or mainly focused on solving the path computation problem within a
over different domains in MPLS networks. As the same case with MPLS, domain or over different domains in MPLS networks. As the same case
service providers (SPs) have also come up with requirements for path with MPLS, service providers (SPs) have also come up with
computation in GMPLS-controlled networks [RFC3945] such as requirements for path computation in GMPLS-controlled networks
wavelength, TDM-based or Ethernet-based networks as well. [RFC3945] such as wavelength, TDM-based or Ethernet-based networks as
well.
[RFC4655] and [RFC4657] discuss the framework and requirements for [RFC4655] and [RFC4657] discuss the framework and requirements for
PCE on both packet MPLS networks and GMPLS-controlled networks. This PCE on both packet MPLS networks and GMPLS-controlled networks. This
document complements these RFCs by providing some considerations of document complements these RFCs by providing some considerations of
GMPLS applications in the intra-domain and inter-domain networking GMPLS applications in the intra-domain and inter-domain networking
environments and indicating a set of requirements for the extended environments and indicating a set of requirements for the extended
definition of PCE-related protocols. definition of PCE-related protocols.
Note that the requirements for inter-layer and inter-area traffic Note that the requirements for inter-layer and inter-area traffic
engineering described in [RFC6457] and [RFC4927] are outside of the engineering described in [RFC6457] and [RFC4927] are outside of the
skipping to change at page 3, line 12 skipping to change at page 3, line 13
(LSPs) is usually more stringent than that of MPLS TE LSPs [RFC4216], (LSPs) is usually more stringent than that of MPLS TE LSPs [RFC4216],
because the additional constraints, e.g., interface switching because the additional constraints, e.g., interface switching
capability, link encoding, link protection capability, SRLG (Shared capability, link encoding, link protection capability, SRLG (Shared
risk link group) [RFC4202] and so forth need to be considered to risk link group) [RFC4202] and so forth need to be considered to
establish GMPLS LSPs. GMPLS signaling protocol [RFC3473] is designed establish GMPLS LSPs. GMPLS signaling protocol [RFC3473] is designed
taking into account bi-directionality, switching type, encoding type taking into account bi-directionality, switching type, encoding type
and protection attributes of the TE links spanned by the path, as and protection attributes of the TE links spanned by the path, as
well as LSP encoding and switching type of the end points, well as LSP encoding and switching type of the end points,
appropriately. appropriately.
This document provides the investigated results of GMPLS applications This document provides requirements for GMPLS applications of PCE in
of PCE for the support of GMPLS path computation. This document also support of GMPLS path computation, included are requirements for both
provides requirements for GMPLS applications of PCE in GMPLS intra- intra-domain and inter-domain environments.
domain and inter-domain environments.
2. GMPLS applications of PCE 2. GMPLS applications of PCE
2.1. Path computation in GMPLS network 2.1. Path computation in GMPLS network
Figure 1 depicts a typical GMPLS network, consisting of an ingress Figure 1 depicts a model GMPLS network, consisting of an ingress
link, a transit link as well as an egress link, to investigate a link, a transit link as well as an egress link. We will use this
consistent guideline for GMPLS path computation. Each link at each model to investigate consistent guidelines for GMPLS path
interface has its own switching capability, encoding type and computation. Each link at each interface has its own switching
bandwidth. capability, encoding type and bandwidth.
Ingress Transit Egress Ingress Transit Egress
+-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+ +-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+
|Node1|------------>|Node2|------------>|Node3|------------>|Node4| |Node1|------------>|Node2|------------>|Node3|------------>|Node4|
| |<------------| |<------------| |<------------| | | |<------------| |<------------| |<------------| |
+-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+ +-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+
Figure 1: Path computation in GMPLS networks Figure 1: Path computation in GMPLS networks
For the simplicity in consideration, the below basic assumptions are For the simplicity in consideration, the below basic assumptions are
skipping to change at page 4, line 13 skipping to change at page 4, line 13
usually responsible for transmitting data for the client layer. usually responsible for transmitting data for the client layer.
These GMPLS-controlled networks can provide different types of These GMPLS-controlled networks can provide different types of
connections for customer services based on different service connections for customer services based on different service
bandwidth requests. bandwidth requests.
The applications and the corresponding additional requirements for The applications and the corresponding additional requirements for
applying PCE to, for example, GMPLS-based TDM networks, are described applying PCE to, for example, GMPLS-based TDM networks, are described
in Figure 2. In order to simplify the description, this document in Figure 2. In order to simplify the description, this document
just discusses the scenario in SDH networks as an example. The just discusses the scenario in SDH networks as an example. The
scenarios in SONET or G.709 ODUk layer networks are similar to this scenarios in SONET or OTN are similar to this scenario.
scenario.
N1 N2 N1 N2
+-----+ +------+ +------+ +-----+ +------+ +------+
| |-------| |--------------| | +-------+ | |-------| |--------------| | +-------+
+-----+ | |---| | | | | +-----+ | |---| | | | |
A1 +------+ | +------+ | | A1 +------+ | +------+ | |
| | | +-------+ | | | +-------+
| | | PCE | | | PCE
| | | | | |
| +------+ | | +------+ |
skipping to change at page 4, line 41 skipping to change at page 4, line 40
| | | | +-----+ | | | | +-----+
| |--------------| |--------| | | |--------------| |--------| |
+------+ +------+ +-----+ +------+ +------+ +-----+
N3 N4 A2 N3 N4 A2
Figure 2: A simple TDM (SDH) network Figure 2: A simple TDM (SDH) network
Figure 2 shows a simple TDM (SDH) network topology, where N1, N2, N3, Figure 2 shows a simple TDM (SDH) network topology, where N1, N2, N3,
N4 and N5 are all SDH switches. Assume that one Ethernet service 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 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 client Ethernet service could be provided by a VC4 container from N1
to N4, and it could also be provided by three concatenated VC3 to N4, and it could also be provided by three concatenated VC3
connections (Contiguous or Virtual concatenation) from N1 to N4. containers (Contiguous or Virtual concatenation) from N1 to N4.
In this scenario, when the ingress node (e.g., N1) receives a client In this scenario, when the ingress node (e.g., N1) receives a client
service transmitting request, the type of connections (one VC4 or service transmitting request, the type of containers (one VC4 or
three concatenated VC3) could be determined by PCC (Path computation three concatenated VC3) could be determined by PCC (Path computation
client) (e.g., N1 or NMS), but could also be determined by PCE client) (e.g., N1 or NMS), but could also be determined by PCE
automatically based on policy [RFC5394]. If it is determined by PCC, automatically based on policy [RFC5394]. If it is determined by PCC,
PCC should be capable of specifying the ingress node and egress node, PCC should be capable of specifying the ingress node and egress node,
signal type, the type of the concatenation and the number of the signal type, the type of the concatenation and the number of the
concatenation in a PCReq (Path computation request) message. PCE concatenation in a PCReq (Path computation request) message. PCE
should consider those parameters during path computation. The route should consider those parameters during path computation. The route
information (co-route or separated-route) should be specified in a information (co-route or separated-route) should be specified in a
PCRep (Path computation reply) message if path computation is PCRep (Path computation reply) message if path computation is
performed successfully. performed successfully.
skipping to change at page 5, line 42 skipping to change at page 5, line 41
the path computation, the PCE should be capable of computing a path the path computation, the PCE should be capable of computing a path
for the bidirectional LSP with asymmetric bandwidth. It means that for the bidirectional LSP with asymmetric bandwidth. It means that
the PCC should be able to indicate the asymmetric bandwidth the PCC should be able to indicate the asymmetric bandwidth
requirements in forward and reverse directions in the PCReq message. requirements in forward and reverse directions in the PCReq message.
3. Requirements for GMPLS application of PCE 3. Requirements for GMPLS application of PCE
3.1. Requirements on Path Computation Request 3.1. Requirements on Path Computation Request
As for path computation in GMPLS-controlled networks as discussed in As for path computation in GMPLS-controlled networks as discussed in
section 2, the PCE should consider the GMPLS TE attributes section 2, the PCE should appropriately consider the GMPLS TE
appropriately once a PCC or another PCE requests a path computation. attributes listed below once a PCC or another PCE requests a path
Indeed, the path calculation request message from the PCC or the PCE computation. The path calculation request message from the PCC or
must contain the information specifying appropriate attributes. the PCE must contain the information specifying appropriate
According to [RFC5440], [PCE-WSON-REQ] and to RSVP procedures like attributes. According to [RFC5440], [PCE-WSON-REQ] and to RSVP
explicit label control(ELC),the additional attributes introduced are procedures like explicit label control(ELC),the additional attributes
as follows: introduced are as follows:
(1) Switching capability/type: as defined in [RFC3471], [RFC4203] (1) Switching capability/type: as defined in [RFC3471], [RFC4203]
and, all current and future values. and, all current and future values.
(2) Encoding type: as defined in [RFC3471], [RFC4203] and, all (2) Encoding type: as defined in [RFC3471], [RFC4203] and, all
current and future values. current and future values.
(3) Signal Type: as defined in [RFC4606] and, all current and future (3) Signal Type: as defined in [RFC4606] and, all current and future
values. values.
(4) Concatenation Type: In SDH/SONET and G.709 ODUk networks, two (4) Concatenation Type: In SDH/SONET and OTN, two kinds of
kinds of concatenation modes are defined: contiguous concatenation concatenation modes are defined: contiguous concatenation which
which requires co-route for each member signal and requires all the requires co-route for each member signal and requires all the
interfaces along the path to support this capability, and virtual interfaces along the path to support this capability, and virtual
concatenation which allows diverse routes for the member signals and concatenation which allows diverse routes for the member signals and
only requires the ingress and egress interfaces to support this only requires the ingress and egress interfaces to support this
capability. Note that for the virtual concatenation, it also may capability. Note that for the virtual concatenation, it also may
specify co-routed or separated-routed. See [RFC4606] and [RFC4328] specify co-routed or separated-routed. See [RFC4606] and [RFC4328]
about concatenation information. about concatenation information.
(5) Concatenation Number: Indicates the number of signals that are (5) Concatenation Number: Indicates the number of signals that are
requested to be contiguously or virtually concatenated. Also see requested to be contiguously or virtually concatenated. Also see
[RFC4606] and [RFC4328]. [RFC4606] and [RFC4328].
skipping to change at page 8, line 12 skipping to change at page 8, line 12
When a PCC specifies the protection type of an LSP, the PCE should When a PCC specifies the protection type of an LSP, the PCE should
compute the working route and the corresponding protection route(s). compute the working route and the corresponding protection route(s).
Therefore, the PCRep should allow to distinguish the working Therefore, the PCRep should allow to distinguish the working
(nominal) and the protection routes. According to these routes, (nominal) and the protection routes. According to these routes,
RSVP-TE procedure appropriately creates both the working and the RSVP-TE procedure appropriately creates both the working and the
protection LSPs for example with ASSOCIATION object [RFC6689]. protection LSPs for example with ASSOCIATION object [RFC6689].
3.3. GMPLS PCE Management 3.3. GMPLS PCE Management
PCE-related Management Information Bases must consider extensions to This document does not change any of the management or operational
be satisfied with requirements for GMPLS applications. For details for networks that utilise PCE. Please refer to [RFC4655] for
extensions, [RFC4802] are defined to manage TE database and may be an overview of this scenery. However, this document proposes the
referred to so as to accommodate GMPLS TE attributes in the PCE. introduction of several PCEP objects and data for the better
integration of PCE with GMPLS networks. Those protocol elements will
need to be visible in any management tools that apply to the PCE,
PCC, and PCEP. That includes, but is not limited to, adding
appropriate objects to existing PCE MIB modules that are used for
modelling and monitoring PCEP deployments [PCEP-MIB]. Ideas for what
objects are needed may be guided by the relevant GMPLS extensions in
GMPLS-TE-STD-MIB [RFC4802]."
4. Security Considerations 4. Security Considerations
PCEP extensions to support GMPLS should be considered under the same PCEP extensions to support GMPLS should be considered under the same
security as current PCE work. This extension will not change the security as current PCE work and this extension will not change the
underlying security issues. underlying security issues. Sec. 10 of [RFC5440] describes the list
of security considerations in PCEP. At the time [RFC5440] was
published, TCP Authentication Option (TCP-AO) had not been fully
specified for securing the TCP connections that underlie PCEP
sessions. TCP-AO [RFC5925] has now been published and PCEP
implementations should fully support TCP-AO according to [RFC6952].
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. Acknowledgement 6. Acknowledgement
The author would like to express the thanks to Ramon Casellas, Julien The author would like to express the thanks to Ramon Casellas, Julien
Meuric, Adrian Farrel and Shuichi Okamoto for their comments. Meuric, Adrian Farrel, Yaron Sheffer and Shuichi Okamoto for their
comments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471, (GMPLS) Signaling Functional Description", RFC 3471,
January 2003. January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
skipping to change at page 10, line 27 skipping to change at page 10, line 35
[RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC [RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC
6689, July 2012. 6689, July 2012.
7.2. Informative References 7.2. Informative References
[PCE-WSON-REQ] [PCE-WSON-REQ]
Lee, Y., Bernstein, G., Martensson, J., Takeda, T., Lee, Y., Bernstein, G., Martensson, J., Takeda, T.,
Tsuritani, T., and O. de Dios, "PCEP Requirements for WSON Tsuritani, T., and O. de Dios, "PCEP Requirements for WSON
Routing and Wavelength Assignment", draft-ietf-pce-wson- Routing and Wavelength Assignment", draft-ietf-pce-wson-
routing-wavelength-08 (work in progress), October 2012. routing-wavelength-09 (work in progress), June 2013.
[PCEP-MIB]
Koushik, A., Emile, S., Zhao, Q., King, D., and J.
Hardwick, "PCE communication protocol (PCEP) Management
Information Base", draft-ietf-pce-pcep-mib-05 (work in
progress), July 2013.
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System
(AS) Traffic Engineering (TE) Requirements", RFC 4216, (AS) Traffic Engineering (TE) Requirements", RFC 4216,
November 2005. November 2005.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657, Communication Protocol Generic Requirements", RFC 4657,
skipping to change at page 11, line 5 skipping to change at page 11, line 17
Engineering", RFC 4726, November 2006. Engineering", RFC 4726, November 2006.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, April 2007. Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394, "Policy-Enabled Path Computation Framework", RFC 5394,
December 2008. December 2008.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[RFC6457] Takeda, T. and A. Farrel, "PCC-PCE Communication and PCE [RFC6457] Takeda, T. and A. Farrel, "PCC-PCE Communication and PCE
Discovery Requirements for Inter-Layer Traffic Discovery Requirements for Inter-Layer Traffic
Engineering", RFC 6457, December 2011. Engineering", RFC 6457, December 2011.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013.
Authors' Addresses Authors' Addresses
Tomohiro Otani Tomohiro Otani
KDDI Corporation KDDI Corporation
2-3-2 Nishi-shinjuku 2-3-2 Nishi-shinjuku
Shinjuku-ku, Tokyo Shinjuku-ku, Tokyo
Japan Japan
Phone: +81-(3) 3347-6006 Phone: +81-(3) 3347-6006
Email: tm-otani@kddi.com Email: tm-otani@kddi.com
 End of changes. 20 change blocks. 
44 lines changed or deleted 70 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/