Internet DRAFT - draft-okamoto-ccamp-midori-gmpls-extension-reqs
draft-okamoto-ccamp-midori-gmpls-extension-reqs
Network Working Group S. Okamoto
Internet Draft Keio University
Intended status: Informational March 15, 2013
Expires: September 2013
Requirements of GMPLS Extensions for Energy Efficient Traffic
Engineering
draft-okamoto-ccamp-midori-gmpls-extension-reqs-02.txt
Status of this Memo
This Internet-Draft is submitted 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 September 15, 2013.
Copyright Notice
Copyright (c) 2013 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.
Abstract
Okamoto Expires September 15, 2013 [Page 1]
Internet-Draft Energy Efficient Traffic Engineering March 2013
This document discusses some of extensions required in existing GMPLS
OSPF routing protocol, RSVP signaling protocol, and LMP to support
the energy efficient traffic engineering technology.
Table of Contents
1. Introduction ................................................ 2
1.1. Conventions used in this document ....................... 3
2. Energy efficient traffic engineering extensions .............. 3
2.1. TE link status ......................................... 3
2.2. LSP status ............................................. 4
2.3. Link power on/off control
............................... 4
2.4. Notify control ......................................... 5
3. Security Considerations
...................................... 5
4. IANA Considerations ......................................... 5
5. References .................................................. 5
5.1. Normative References
.................................... 5
5.2. Informative References
.................................. 6
6. Acknowledgments ............................................. 7
1. Introduction
The Generalized Multiprotocol Label Switching (GMPLS) [RFC3945]
protocol suite is designed to provide a control plane for a range of
network technologies including packet/frame switching networks
including MPLS routers and Ethernet switches, optical networks such
as time division multiplexing (TDM) networks including SONET/SDH and
Optical Transport Networks (OTNs), and lambda switching optical
networks.
In GMPLS controlled networks, the network is described by label
switch routers (LSRs) and traffic engineering (TE) links. A TE link
is advertised as an adjunct to a "physical" link. When the link is up,
both the regular Internal Gateway Protocol (IGP) properties of the
link (basically, the Shortest Path First (SPF) metric) and the TE
properties of the link (such as bandwidth and switching capability)
are then advertised. Therefore, basically, if the link is down then
the TE link is also down. A TE link is not only defined between IGP
neighbors but also defined on a Forwarding Adjacency (FA) label
switched path (LSP). An LSP is composed with cross-connection of TE
links. Therefore, if the composed TE link is down then the LSP is
also down.
An energy efficient Internet [I-D.winter-energy-effcient-internet], a
power aware networking (PANET) [I-D.dong-panet-requirements], and an
energy aware control plane [I-D.retana-rtgwg-eacp] are discussed.
Okamoto Expires September 15, 2013 [Page 2]
Internet-Draft Energy Efficient Traffic Engineering March 2013
Energy efficient traffic engineering technology is also discussed in
[Yonezu][Cerutiti.ECOC][Cerutiti.JLT]. Under the energy efficient
traffic engineering, LSPs are rerouted to use lest number of links,
then some links are physically shutdown to reduce power consumption
of equipment. In traditional GMPLS networks, TE links associated in
shutdown links are also down. Therefore, when emergency occurred,
such as traffic explosion and link/equipment failure, downed TE links
are not able to use for calculating protection LSP and LSP rerouting.
This document defines requirements for extending GMPLS protocols to
support the energy efficient traffic engineering features.
1.1. 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].
2. Energy efficient traffic engineering extensions
Protocol extensions of OSPF, RSVP, and Link Management Protocol (LMP)
are required to support new TE link status, new LSP status, link
power on/off capability, and new notify control feature.
2.1. TE link status
[RFC2328] defines Interface states for describing "Interface State
changes" and "Interface State Machine". A link status "Up" and "Down"
can be get from the Interface states.
[RFC3630] defines the Traffic Engineering properties of TE links and
defines Link Type/Length/Value (TLV) for TE link properties
advertisement. A Link-TLV has some sub-TLVs, however, there is no TE
link status information. [RFC4203] adds some sub-TLVs to the Link-TLV
in support of GMPLS.
As a conclusion, a TE link does not have any status indication. If
Link becomes down then value(s) of the Traffic Engineering Metric
sub-TLV, and/or the Maximum bandwidth sub-TLV, and/or the Maximum
Reservable Bandwidth sub-TLV in associated TE links are changed
according with the network operator's policy.
Under the energy efficient TE environment, the link down by
administrative operation or link failure, and link power down by the
energy efficient TE should be distinguished in the route calculation
system such as Constraint Shortest Path First (CSPF) and Path
Computation Entity (PCE).
Okamoto Expires September 15, 2013 [Page 3]
Internet-Draft Energy Efficient Traffic Engineering March 2013
A TE link state sub-TLV which indicates power off state of the TE
link is required.
2.2. LSP status
[RFC3471], [RFC3473], and [RFC4974] defines the Administrative Status
Information in the Admin_Status object. The defined status bits are
Reflect (R), Testing (T), Administratively down (A), Deletion in
progress (D), and Call Management (C).
In the energy efficient TE environment, an LSP which includes power
off TE link(s) as LSP component can be defined. This LSP can be
assigned as a backup LSP. The backup LSP which does not contain power
of link(s) can be used as 1+1 protection, 1:N protection w/wo extra
traffic, shared protection, and restoration. On the other hand, the
backup LSP which contains power off link(s) can be used as 1:N
protection wo extra traffic, shared protection, and restoration. When
activating the LSP, power up of link(s) is required.
To distinguish the backup LSP which contains the power off link(s) or
not, new LSP status should be defined in the Admin_Status object.
2.3. Link power on/off control
The energy efficient TE requires link power on/off control function.
There are two possible implementation, one is using LMP the other is
using RSVP.
When using LMP, power on (or off) initiator LSR sends power on (or
off) request to the neighbor LSR. The neighbor LSR sends Ack to the
initiator LSR and power on (or off) the link and changes the TE link
status. Then the initiator LSR receives Ack and power on (or off) the
link and changes the TE link status.
The power control should be included to the LMP.
Note: to apply the power on procedure, IP control channel (IPCC)
should be always up. Therefore, a dedicated IPCC is required to apply
the LMP control.
When using RSVP, sequentially concatenated TE links can be controlled.
There are two procedure candidates in the power off procedure.
[Power On] All TE links along with the LSP are power on.
[Power Off]
Okamoto Expires September 15, 2013 [Page 4]
Internet-Draft Energy Efficient Traffic Engineering March 2013
1. All TE links along with the LSP are power off. If other LSPs share
the TE links then the LSPs should be rerouted.
2. All TE links but not shared by other LSPs are power off.
Both procedures are used according with the network operator's policy.
It may be required with LSP graceful shutdown procedure to notify the
link power off completion to the initiator.
Power control request may be implemented in the Admin_Status object.
2.4. Notify control
The power off procedure option #1 described in 2.3 can be applicable
not only to a single layer network but also to a multi-layer network.
If the server layer TE-link becomes the "power off" state, upper
layer LSP segment detects the status change and sends NOTIFY message
to an LSP ingress node. The ingress node reroutes the LSP or changes
the LSP status to "power off".
3. Security Considerations
TBD
4. IANA Considerations
TBD
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3945] Mannie, E. (Editor), "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
Okamoto Expires September 15, 2013 [Page 5]
Internet-Draft Energy Efficient Traffic Engineering March 2013
[RFC3630] Katz, D., Kompella, K., Yeung, D., "Traffic Enginnering
(TE) Extensions to OSPF Version 2", RFC 3630, September
2003.
[RFC4203] Kompella, K., and Rekhter, Y. (Editors), "OSPF Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005.
[RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3473] Berger, L. (Editor), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003.
[RFC4974] Papadimitriou, D., and Farrel, A., "Generalized MPLS
(GMPLS) RSVP-TE Signaling Extensions", RFC 4974, August
2007.
5.2. Informative References
[I-D.winter-energy-efficient-internet] Winter, R., Jeong, S., Choi,
JH., "Towards an Energy-Efficient Internet", draft-winter-
energy-efficient-internet-01.txt (work in progress), October
2012.
[I-D.dong-panet-requirements] Dong, J., Zhang, M., Zhang, B.,
Boucadair, M., "Requirements for Power Aware Network", draft-
dong-panet-requirements-01.txt (work in progress), February
2013.
[I-D.retana-rtgwg-eacp] Retana, A., White, R., Paul, M., "A Framework
and Requirements for Energy Aware Control Planes", draft-
retana-rtgwg-eacp-01.txt (work in progress), February 2013.
[Yonezu] Yonezu, H., Kikuta, K., Ishii, D., Okamoto, S., Oki, E., and
Yamanaka, N., "QoS Aware Energy Optimal Network Topology Design
and Dynamic Link Power Management", Proc. ECOC 2010 Tu.3.D.4.
[Cerutiti.ECOC]
Cerutiti I., Sambo, N., and Castoldi, P., "Distributed
support of link sleep mode foe energy efficient GMPLS networks",
Proc. ECOC 2010 P5.11.
Okamoto Expires September 15, 2013 [Page 6]
Internet-Draft Energy Efficient Traffic Engineering March 2013
[Cerutiti.JLT] Cerutiti I., Sambo, N., and Castoldi, P., "Sleeping
Link Selection for Energy-Efficient GMPLS Networks", IEEE
Journal of Lightwave Technology, Vol. 29, No. 15, pp.2292-2298,
Aug. 2011.
6. Acknowledgments
The author would like to thank Prof. Naoaki Yamanaka and all members
of the Interoperability Working Group, Kei-han-na Open Laboratories
for their useful comments and suggestions.
Author's Addresses
Satoru Okamoto
Keio University
3-14-1 Hiyoshi, Kohoku-ku
Yokohama, Kanagawa 223-8522 Japan
Email: okamoto@ieee.org
Okamoto Expires September 15, 2013 [Page 7]
