draft-ietf-pce-gmpls-aps-req-05.txt   draft-ietf-pce-gmpls-aps-req-06.txt 
Network Working Group Tomohiro Otani Network Working Group Tomohiro Otani
Internet-Draft KDDI Internet-Draft KDDI
Intended status: Informational Kenichi Ogaki Intended status: Informational Kenichi Ogaki
KDDI R&D Labs KDDI R&D Labs
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Fatai Zhang Fatai Zhang
Huawei Huawei
Expires: July 06, 2012 January 06, 2012 Expires: December 27, 2012 June 27, 2012
Requirements for GMPLS applications of PCE Requirements for GMPLS applications of PCE
Document: draft-ietf-pce-gmpls-aps-req-05.txt Document: draft-ietf-pce-gmpls-aps-req-06.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 06, 2012. This Internet-Draft will expire on December 27, 2012.
Abstract Abstract
The initial effort of PCE WG is specifically focused on MPLS (Multi- The initial effort of PCE WG is specifically focused on MPLS (Multi-
protocol label switching). As a next step, this draft describes protocol label switching). As a next step, this draft describes
functional requirements for GMPLS (Generalized MPLS) application of functional requirements for GMPLS (Generalized MPLS) application of
PCE (Path computation element). PCE (Path computation element).
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction ................................................. 2 1. Introduction ................................................. 2
2. Terminology .................................................. 3 2. Terminology .................................................. 3
3. GMPLS applications of PCE..................................... 3 3. GMPLS applications of PCE .................................... 3
3.1. GMPLS network model...................................... 3 3.1. GMPLS network model ..................................... 3
3.2. Path computation in GMPLS network ........................4 3.2. Path computation in GMPLS network ....................... 4
3.3. Unnumbered Interfaces.................................... 6 3.3. Unnumbered Interfaces ................................... 6
3.4. Asymmetric Bandwidth Path Computation ................... 6 3.4. Asymmetric Bandwidth Path Computation ................... 6
4. Requirements for GMPLS application of PCE .................... 6 4. Requirements for GMPLS application of PCE .................... 6
4.1. Requirements of Path Computation Request ................ 6 4.1. Requirements of Path Computation Request ................ 6
4.2. Requirements of Path Computation Reply .................. 8 4.2. Requirements of Path Computation Reply .................. 8
4.3. GMPLS PCE Management..................................... 9 4.3. GMPLS PCE Management .................................... 9
5. Security consideration........................................ 9 5. Security consideration ....................................... 9
6. IANA Considerations .......................................... 9 6. IANA Considerations .......................................... 9
7. Acknowledgement .............................................. 9 7. Acknowledgement .............................................. 9
8. References ................................................... 9 8. References ................................................... 9
9. Authors' Addresses ........................................... 12 8.1. Normative References..................................... 9
8.2. Informative References................................... 11
9. Authors' Addresses ........................................... 13
1. Introduction 1. Introduction
The initial effort of PCE WG is focused on solving the path The initial effort of PCE WG is focused on solving the path
computation problem within a domain or over different domains in computation problem within a domain or over different domains in
MPLS networks. As the same case with MPLS, service providers (SPs) MPLS networks. As the same case with MPLS, service providers (SPs)
have also come up with requirements for path computation in GMPLS have also come up with requirements for path computation in GMPLS
networks such as wavelength, TDM-based or Ethernet-based networks as networks such as wavelength, TDM-based or Ethernet-based networks as
well. 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 (non-packet switch capable) PCE on both packet MPLS networks and (non-packet switch capable)
GMPLS networks. This document complements these documents by GMPLS networks. This document complements these documents by
providing some considerations of GMPLS applications in the intra- providing some considerations of GMPLS applications in the intra-
domain and inter-domain networking environments and indicating a set domain and inter-domain networking environments and indicating a set
of requirements for the extended definition of series of PCE related of requirements for the extended definition of series of PCE related
protocols. protocols.
Note that the requirements for inter-layer traffic engineering Note that the requirements for inter-layer traffic engineering
described in [PCE-INTER LAYER-REQ] are outside of the scope of this described in [RFC6457] are outside of the scope of this document.
document.
Constraint based shortest path first (CSPF) computation within a Constraint based shortest path first (CSPF) computation within a
domain or over domains for signaling GMPLS Label Switched Paths domain or over domains for signaling GMPLS Label Switched Paths
(LSPs) is more stringent than that of MPLS TE LSPs [RFC4216], (LSPs) is 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 and so forth capability, link encoding, link protection capability and so forth
need to be considered to establish GMPLS LSPs [CSPF]. GMPLS need to be considered to establish GMPLS LSPs [CSPF]. GMPLS
signaling protocol [RFC3471, RFC3473] is designed taking into signaling protocol [RFC3471, RFC3473] is designed taking into
account bi-directionality, switching type, encoding type, SRLG, and account bi-directionality, switching type, encoding type, SRLG, and
protection attributes of the TE links spanned by the path, as well protection attributes of the TE links spanned by the path, as well
skipping to change at page 6, line 31 skipping to change at page 6, line 29
GMPLS supports unnumbered interface ID that is defined in [RFC 3477], GMPLS supports unnumbered interface ID that is defined in [RFC 3477],
which means that the endpoints of the path may be unnumbered. It which means that the endpoints of the path may be unnumbered. It
should also be possible to request a path consisting of the mixture should also be possible to request a path consisting of the mixture
of numbered links and unnumbered links, or a P2MP path with of numbered links and unnumbered links, or a P2MP path with
different types of endpoints. Therefore, the PCC should be capable different types of endpoints. Therefore, the PCC should be capable
of indicating the unnumbered interface ID of the endpoints in the of indicating the unnumbered interface ID of the endpoints in the
PCReq message. PCReq message.
3.4. Asymmetric Bandwidth Path Computation 3.4. Asymmetric Bandwidth Path Computation
As per [RFC5467], GMPLS signaling can be used for setting up an As per [RFC6387], GMPLS signaling can be used for setting up an
asymmetric bandwidth bidirectional LSP. If a PCE is responsible for asymmetric bandwidth bidirectional LSP. If a PCE is responsible for
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.
4. Requirements for GMPLS application of PCE 4. Requirements for GMPLS application of PCE
In this section, we describe requirements for GMPLS applications of In this section, we describe requirements for GMPLS applications of
PCE in order to establish GMPLS LSP. PCE in order to establish GMPLS LSP.
skipping to change at page 7, line 36 skipping to change at page 7, line 32
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].
(6) Technology specific label(s) such as wavelength label as defined (6) Technology specific label(s) such as wavelength label as defined
in [RFC6205]. in [RFC6205], or labels defined in [RFC4606], [RFC6060] or [RFC6002].
(7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1 (7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1
protection, 1:1 protection, (pre-planned) rerouting, etc. protection, 1:1 protection, (pre-planned) rerouting, etc.
(8) Administrative group: as defined in [RFC3630]. (8) Administrative group: as defined in [RFC3630].
(9) Link Protection type: as defined in [RFC4203]. (9) Link Protection type: as defined in [RFC4203].
(10)Support for unnumbered interfaces: as defined in [RFC3477]. (10)Support for unnumbered interfaces: as defined in [RFC3477].
(11)Support for asymmetric bandwidth request: as defined in (11)Support for asymmetric bandwidth request: as defined in
[RFC5467]. [RFC6387].
(12)Support for explicit label control during the path computation. (12)Support for explicit label control during the path computation.
(13) The PCC/PCE should be able to provide label restrictions
similar to RSVP on the requests/responses
4.2. Requirements of Path Computation Reply 4.2. Requirements of Path Computation Reply
As described above, a PCC must support to initiate a PCReq message As described above, a PCC must support to initiate a PCReq message
specifying above mentioned attributes. The PCE should compute the specifying above mentioned attributes. The PCE should compute the
path that satisfies the constraints which are specified in the PCReq path that satisfies the constraints which are specified in the PCReq
message. Then the PCE should send a PCRep message including the message. Then the PCE should send a PCRep message including the
computation result to the PCC. For Path Computation Reply message computation result to the PCC. For Path Computation Reply message
(PCRep) in GMPLS networks, there are some additional requirements. (PCRep) in GMPLS networks, there are some additional requirements.
The PCEP PCRep message must be extended to meet the following The PCEP PCRep message must be extended to meet the following
requirements. requirements.
skipping to change at page 8, line 39 skipping to change at page 8, line 39
For virtual concatenation path computation, only the ingress/egress For virtual concatenation path computation, only the ingress/egress
interfaces need to support virtual concatenation capability and interfaces need to support virtual concatenation capability and
maybe there are diverse routes for the different member signals. maybe there are diverse routes for the different member signals.
Therefore, multiple EROs may be needed for the response. Each ERO Therefore, multiple EROs may be needed for the response. Each ERO
may represent the route of one or multiple member signals. In the may represent the route of one or multiple member signals. In the
case that one ERO represents several member signals among the total case that one ERO represents several member signals among the total
member signals, the number of member signals along the route of the member signals, the number of member signals along the route of the
ERO must be specified. ERO must be specified.
(2) Wavelength label (2) Label constraint
In the case that a PCC doesn't specify the wavelength when In the case that a PCC doesn't specify the label when requesting a
requesting a wavelength path and the PCE is capable of performing label-resctricted path and the PCE is capable of performing the
the route and wavelength computation procedure, the PCE should be route and label assignment computation procedure, the PCE needs to
able to specify the wavelength of the path in a PCRep message. be able to specify the label of the path in a PCRep message.
Wavelength restriction is a typical case of label restriction but is
only one instance of it. More generally in GMPLS networks label
switching and selection constraint may apply and a PCC may request a
PCE to take label constraint into account and return an ERO
containing the labels or set of label that fulfill the PCC request.
The PCReq aspects are covered in section 4.1 in the requirements 6,
12 and 13.
(3) Roles of the routes (3) Roles of the routes
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 be capable of indicating which one is Therefore, the PCRep should be capable of indicating which one is
working or protection route. working or protection route.
4.3. GMPLS PCE Management 4.3. GMPLS PCE Management
skipping to change at page 9, line 25 skipping to change at page 9, line 35
security as current PCE work. This extension will not change the security as current PCE work. This extension will not change the
underlying security issues. underlying security issues.
6. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. Acknowledgement 7. Acknowledgement
The author would like to express the thanks to Shuichi Okamoto for The author would like to express the thanks to Shuichi Okamoto for
his comments. their comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to indicate [RFC2119] S. Bradner, "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997. requirements levels", RFC 2119, March 1997.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(MPLS) Signaling Functional Description", RFC 3471, (MPLS) Signaling Functional Description", RFC 3471,
skipping to change at page 10, line 17 skipping to change at page 10, line 27
RFC4202, Oct. 2005. RFC4202, Oct. 2005.
[RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in Support [RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching", RFC4203, of Generalized Multi-Protocol Label Switching", RFC4203,
Oct. 2005. Oct. 2005.
[RFC4328] D. Papadimitriou, Ed., "Generalized Multi-Protocol Label [RFC4328] D. Papadimitriou, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC4328, January 2006. Transport Networks Control", RFC4328, January 2006.
[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
Switched Paths (LSPs)", RFC 6387, September 2011.
[RFC4606] E. Mannie and D. Papadimitriou, "Generalized Multi- [RFC4606] E. Mannie and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC4606, August 2006. Digital Hierarchy (SDH) Control", RFC4606, August 2006.
[RFC4657] J. Ash, et al, "Path computation element (PCE)
communication protocol generic requirements", RFC4657,
Sept., 2007.
[RFC4802] T. Nadeau and A. Farrel, Ed., "Generalized Multiprotocol [RFC4802] T. Nadeau and A. Farrel, Ed., "Generalized Multiprotocol
Label Switching (GMPLS) Traffic Engineering Management Label Switching (GMPLS) Traffic Engineering Management
Information Base", RFC4802, Feb. 2007. Information Base", RFC4802, Feb. 2007.
[RFC4872] J.P. Lang, Ed., "RSVP-TE Extensions in Support of End-to- [RFC4872] J.P. Lang, Ed., "RSVP-TE Extensions in Support of End-to-
End Generalized Multi-Protocol Label Switching (GMPLS) End Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC4872, May 2007. Recovery", RFC4872, May 2007.
[RFC5476] B.Claise,Ed,"Packet Sampling(PSAMP) Protocol [RFC5440] J.P. Vasseur, et al, "Path Computation Element (PCE)
Specifications",March 2009.
[RFC5440] J.P. Vasseur, et al, "Path Computation Element (PCE)
Communication Protocol (PCEP)", RFC5440, March 2009. Communication Protocol (PCEP)", RFC5440, March 2009.
[RFC6002] Lou Berger, et al.,"Generalized MPLS (GMPLS) Data Channel [RFC6002] Lou Berger, et al.,"Generalized MPLS (GMPLS) Data Channel
Switching Capable (DCSC) and Channel Set Label Extensions", Switching Capable (DCSC) and Channel Set Label Extensions",
RFC6002, October 2010. RFC6002, October 2010.
[RFC6060] Don Fedyk, et al., "Generalized Multiprotocol Label [RFC6060] Don Fedyk, et al., "Generalized Multiprotocol Label
Switching (GMPLS) control of Ethernet PBB-TE", RFC6060, Switching (GMPLS) control of Ethernet PBB-TE", RFC6060,
March 2011. March 2011.
[RFC6205] T. Otani, Ed., "Generalized Labels for G.694 Lambda- [RFC6205] T. Otani, Ed., "Generalized Labels for G.694 Lambda-
Switching Capable Label Switching Routers", RFC6205, March Switching Capable Label Switching Routers", RFC6205, March
2011 2011
[RFC6387] Takacs, et. al., "GMPLS Asymmetric Bandwidth Bidirectional
Label Switched Paths (LSPs)", RFC6387, September 2011
8.2. Informative References 8.2. Informative References
[RFC4216] R. Zhan, et al, "MPLS Inter-Autonomous System (AS) Traffic
Engineering (TE) Requirements", RFC4216, November 2005.
[RFC4655] A. Farrel, et al, "A Path Computation Element (PCE)-Based
Architecture", RFC4655, Aug., 2006.
[RFC4657] J. Ash, et al, "Path computation element (PCE)
communication protocol generic requirements", RFC4657,
Sept., 2007.
[RFC4726] A. Farrel, et al, "A framework for inter-domain MPLS [RFC4726] A. Farrel, et al, "A framework for inter-domain MPLS
traffic engineering", RFC4726, November 2006. traffic engineering", RFC4726, November 2006.
[RFC5394] I. Bryskin et al., "Policy-Enabled Path Computation [RFC5394] I. Bryskin et al., "Policy-Enabled Path Computation
Framework", RFC5394, December 2008. Framework", RFC5394, December 2008.
[RFC6457] T.Takeda,et al,"PCC-PCE Communication and PCE [RFC6457] T.Takeda,et al,"PCC-PCE Communication and PCE
Discovery Requirements for Inter-Layer Discovery Requirements for Inter-Layer
Engineering",RFC6457,December 2011. Engineering",RFC6457,December 2011.
skipping to change at page 12, line 33 skipping to change at page 13, line 33
Email: diego.caviglia@ericsson.com Email: diego.caviglia@ericsson.com
Fatai Zhang Fatai Zhang
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Phone: +86-755-28972912 Phone: +86-755-28972912
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Cyril Margaria
Nokia Siemens Networks
St Martin Strasse 76
Munich, 81541
Germany
Phone: +49 89 5159 16934
Email: cyril.margaria@nsn.com
Intellectual Property Intellectual Property
The IETF Trust takes no position regarding the validity or scope of The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. such rights.
 End of changes. 20 change blocks. 
29 lines changed or deleted 60 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/