Network Working Group F. Zhang
Internet-Draft F. Gao
Intended status: Informational Y. Bao
Expires: January 4, 2010 ZTE Corpoporation
July 03, 2009
Requirements for PCE Applied in OTN
draft-zhang-pce-reqs-for-otn-00.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 January 4, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes specific requirements for applying Path
Computation Element (PCE) in Optical Transport Networks (OTN).
Zhang, et al. Expires January 4, 2010 [Page 1]
Internet-Draft Requirements for PCE Applied in OTN July 2009
Lightpath provisioning in OTN needs the pre-consideration of the
Optical Data Unit (ODUk) cross connection because of the additional
optical impairments constraints on the Optical Channel (OCh)
lightpath available for use.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . 3
3. PCE Applications . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Requirements when PCC Specifies the Signal Format . . . . . 5
3.2. Requirements when PCE Determines the Signal Format . . . . 5
3.3. Source Routing . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative references . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Zhang, et al. Expires January 4, 2010 [Page 2]
Internet-Draft Requirements for PCE Applied in OTN July 2009
1. Introduction
A Path Computation Element (PCE) is an entity that is able to compute
Label Switched Paths (LSP) in Multiprotocol Label Switching Traffic
Engineering (MPLS-TE) and General MPLS (GMPLS) networks, as defined
in [RFC4655]. Any network element can act as a Path Computation
Client (PCC) that requests the PCE to compute a set of TE-LSPs based
on some kinds of constraints. The communication protocol between PCE
and PCC or between cooperating PCEs is defined in [RFC5440].
G.709 Optical Transport Networks (OTN) are usually responsible for
transmitting data for the client layer, as specified in the ITU-T
G.709 recommendation [G.709]. It provides Optical Channel Data Unit
(ODUk) digital layer and Optical Channel (OCh) optical layer cross
connection based on different service bandwidth requests.
Optical signal along the optical path maybe be altered by the optical
impairments that is classified into two categories, linear and
nonlinear. Linear effects, such as amplifier spontaneous emission
(ASE), polarization mode dispersion (PMD), chromatic dispersion (CD)
are independent of signal power and affect wavelength individually.
However, nonlinearities (such as non-linear phase shift (NLPS)) are
much more complex: they generate not only impairments on each
channel, but also crosstalk between channels. Given that the
existing standards covering optical characteristics (impairments) and
the knowledge of how the impact of impairments may be estimated along
a path, [RFC4054] provides an overview of some critical optical
impairments and their routing Wavelength implications. Framework for
impairment aware path computation based on the PCE architecture in
WSON can be found in [wson-impairments] and
[wson-routing-wavelength].
[wson-impairments] considers pre-setting a limited Bit Error Ratio
(BER) value to estimate the calculated optical path quality. The
limited BER value is dependent on the bit rate, the signal format and
Forwarding Error Coding (FEC), however, the last two factors are
determined by the digital encapsulation. In order to give a
reasonable limited BER value, it is better to consider the ODUK and
OCh layer provisioning together in OTN.
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 [1].
Zhang, et al. Expires January 4, 2010 [Page 3]
Internet-Draft Requirements for PCE Applied in OTN July 2009
3. PCE Applications
Figure 1 shows a simple network topology, where NE1, NE2, NE3, NE4,
NE5 are all OTN equipments, such as OXC, PXC, ROADM, etc. PCE is a
function entity that is incorporated into the NMS or remote from the
NMS using XML or PCEP to communicate with each other. PCE can share
the traffic engineering database (TED) with NMS, get the TED with the
help of IGP-TE, or the network elements (NEs) just send their traffic
parameters directly to PCE using the method described in [PCE-TED].
No matter what methods we can assume that PCE knows the modulation
formats and FEC types NE can support. Here for simplicity, we do not
figure out the position of NMS. Assuming that one Ethernet service
with 40G bandwidth is required from C1 to C3, the required signal
format/FEC needs to be specified by PCC (N1), but could also be
determined by PCE automatically based on policy, configuration, or
network capabilities. This is related to the policies which can be
implemented per [RFC5394]. The requirements described according to
applied policies will list in the next two sections.
+-----+
| PCE |
+-----+
|
|
|
+-----+ +-----+
C1------| NE1 |---------------| NE2 |
+-----+ +-----+
| \ |
| \ |
| \ |
| \+-----+ |
| | NE5 | |
| +-----+ |
| \ |
| \ |
| \ |
+-----+ \ +-----+
| NE4 |---------------| NE3 |------C3
+-----+ +-----+
Figure 1: Simple OTN network
Zhang, et al. Expires January 4, 2010 [Page 4]
Internet-Draft Requirements for PCE Applied in OTN July 2009
3.1. Requirements when PCC Specifies the Signal Format
In this case, the PCC specifies the transport scheme for the service
based on the requested bandwidth and the pre-configured transport
policies when receiving the service request from C1 to C3 from client
layer, then requests the PCE to compute the corresponding path. For
example, the node N1 makes a decision to adopt Differential
Quadrature Phase-Shift Keying (DQPSK) as the signal modulation format
with FEC coding, then it will determine the pre-FEC that should be
specified in the PCReq message. The pre-FEC value is out of the
scope of this document, but apparently should take into account of
the following factors: (1)the format/rate will give a required value
that must be met in the receiver. (2)the degradation caused by PMD,
OSNR, NPLS should be considered in the pre-setting value. (3)the
margin reserved for the future operation/repair. (4)FEC revision.
When receiving the PCReq message, PCE computes the path that
satisfies the set of constraints in the PCReq message. If
successful, the corresponding path will be returned to PCC in the
PCRep message. Note that the PCE should return the calculated BER
value in the PCRep message.
3.2. Requirements when PCE Determines the Signal Format
In this case, when receiving the request for a service from C1 to C3
from the client layer, the PCC sends the PCReq message with the
bandwidth object to the PCE before the ODUK cross connection.
The PCE determines the signal modulation format/FEC function for the
service based on the requested bandwidth, the estimated distance
between N1 and N3, and the pre-configured transport policies after
receiving the PCReq message, whereafter sets the pre-FEC value
considering the factors the same as described in Section 3.1. If PCE
can successfully work out the lightpath that satisfies the limited
BER value , the information of the corresponding signal modulation
format and FEC function will be sent to the PCC in the PCRep message
in order that the PCC can set up the ODUk cross connection correctly.
Of course, the calculated BER value should also be given to the PCC.
3.3. Source Routing
In the transparent optical networks, the middle NE (e.g. N2/N4/N5 in
figure 1) can not see the signal modulation format and FEC type, so
the calculated light path can be end-to-end path from source to
destination. However, the middle NE may terminate the optical signal
in the opaque optical networks. In such cases, the PCE should give
back to PCC the related information that every opaque hop's
modulation format and FEC type. When signaling, PCC put this
Zhang, et al. Expires January 4, 2010 [Page 5]
Internet-Draft Requirements for PCE Applied in OTN July 2009
information in the ERO object of RSVP-TE, so every NE can use this
information to setup the cross connection.
4. IANA Considerations
TBD.
5. Security Considerations
This document just focuses on the requirements of applying PCE in the
OTN networks, so there is no additional security need to be
considered until it need extend PCEP to support these requirements.
6. Acknowledgement
The author would like to thank Xihua Fu for his useful comments.
7. References
7.1. Normative references
[G.698.1] ITU-T Recommendation G.698.1, "Multichannel DWDM
applications with Single-Channel optical interface",
December 2006.
[G.709] ITU-T G.709 Recommendation, "Interface for the Optical
Transport Network (OTN)", February 2001.
[RFC4054] Strand, J. and A. Chiu, "Impairments and Other Constraints
on Optical Layer Routing", RFC 4054, May 2005.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394,
December 2008.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
Zhang, et al. Expires January 4, 2010 [Page 6]
Internet-Draft Requirements for PCE Applied in OTN July 2009
7.2. Informative References
[PCE-TED] Lee, Y. and G. Bernstein, "Alternative Approaches to
Traffic Engineering Database Creation and Maintenance for
Path Computation Elements", May 2009.
[wson-impairments]
Bernstein, G. and Y. Lee, "A Framework for the Control of
Wavelength Switched Optical Networks (WSON) with
Impairments", June 2009.
[wson-routing-wavelength]
Lee, Y. and G. Bernstein, "PCEP Requirements for WSON
Routing and Wavelength Assignment", March 2009.
Authors' Addresses
Fei Zhang
ZTE Corpoporation
68 Zijinghua Road
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86 025 52877612
Email: zhang.fei3@zte.com.cn
Feng Gao
ZTE Corpoporation
ZTE Plaza, 19 Huayuandonglu Road
Haidian District, Beijing 100191
P.R.China
Phone: +86 010 82963969
Email: gao.feng1@zte.com.cn
Yuanlin Bao
ZTE Corpoporation
ZTE Industrial Park, XiLi LiuXian Road
Nanshan District, Shenzhen 518055
P.R.China
Phone: +86 0755 26773731
Email: bao.yuanlin@zte.com.cn
Zhang, et al. Expires January 4, 2010 [Page 7]