Internet DRAFT - draft-zhaoyl-ccamp-p2mp-requirement-flexi-grid
draft-zhaoyl-ccamp-p2mp-requirement-flexi-grid
Network Working Group YL. Zhao
Internet-Draft XS. Yu
Intended status: Informational J. Zhang
Expires: July 13, 2013 BUPT
JY. Wang
XF. Lin
ZTE Corporation
January 9, 2013
Requirements for Supporting P2MP in Flexi-Grid Networks
draft-zhaoyl-ccamp-p2mp-requirement-flexi-grid-01
Abstract
Multicasting over WDM optical networks has enabled many popular
Point-to-Multipoint (P2MP) applications, such as video conference,
interactive distance learning, replicated database, distributed
computing, and so on. However, on the one hand, the low-rate
multicasting traffic demands cannot make full use of the capacity of
the entire wavelength, and on the other hand, new services such as
data center migration and cloud applications need higher transmission
rates and higher spectrum efficiency. Flexi-grid network is an
effective solution to address the problem of transmission rate and
spectrum utilization. It overcomes the fixed grid constraint of
Wavelength Swithched Optical Network (WSON) by using advanced
technologies such as coherent detection and Bandwidth Variable-
Wavelength Selective Switches (BV-WSS). Therefore, it is essential
to exploit multicasting over flexi-grid networks. This document
covers the requirements for supporting P2MP over flexi-grid
infrastructure. Specifically, the scope of requirements listed in
this document covers the functionality that should be supported by
the control plane.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
Zhao, et al. Expires July 13, 2013 [Page 1]
Internet-Draft P2MP in Flexi-Grid Networks January 2013
This Internet-Draft will expire on July 13, 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. 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.
Zhao, et al. Expires July 13, 2013 [Page 2]
Internet-Draft P2MP in Flexi-Grid Networks January 2013
Table of Contents
1. Conventions Used in This Document . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements for Supporting P2MP in Flexi-grid Networks . . . 6
4.1. Requirements description . . . . . . . . . . . . . . . . . 6
4.2. Examples for Requirements . . . . . . . . . . . . . . . . 7
5. Framework of Protocol Extensions . . . . . . . . . . . . . . . 9
5.1. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. PCE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Zhao, et al. Expires July 13, 2013 [Page 3]
Internet-Draft P2MP in Flexi-Grid Networks January 2013
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 [RFC2119].
2. Introduction
Multicasting over WDM optical networks has enabled many popular
Point-to-Multipoint (P2MP) applications, such as video conference,
interactive distance learning, replicated database, distributed
computing, and so on. RFC [4461] presents a set of requirements for
the establishment and maintenance of P2MP Traffic-Engineered (TE)
Label Switched Paths (LSPs). The requirements not only apply to
packet-switched networks under the control of MPLS protocols, but
also encompass the requirements of Layer Two Switching (L2SC), Time
Division Multiplexing (TDM), lambda, and port switching networks
managed by GMPLS protocols. RFC [4875] describes extensions to
Resource reSerVation Protocol - Traffic Engineering (RSVP-TE) for the
setup of Traffic Engineered (TE) based P2MP Label Switched Paths
(LSPs) in MPLS and GMPLS networks. However, the low-rate
multicasting traffic demands cannot make full use of the capacity of
the entire wavelength. Furthermore, new services such as data center
migration and cloud applications need higher transmission rates and
higher spectrum efficiency. Flexi-grid network discussed recently is
an effective solution to address the problem of transmission rate and
spectrum utilization. It overcomes the fixed grid constraint of
Wavelength Swithched Optical Network (WSON) by using advanced
technologies such as coherent detection and Bandwidth Variable-
Wavelength Selective Switches (BV-WSS). It's essential to extend the
protocols to exploit P2MP applications over such flexi-grid networks.
Flexible grid technology is defined in the latest version of ITU-T
G.694.1, which is also a dense wavelength division multiplexing and
different from traditional fixed grid technology. Compared to fixed
grids, flexible grid has a smaller and agile granularity for the
central frequencies and the slot width may range from 12.5GHz to
hundreds of GHz. The flexible grid technology allows mixed bit rates
or mixed modulation formats transmission system to allocate frequency
slots with different slot widths. So that they can be optimized for
the bandwidth requirements of a particular bit rate and modulation
scheme of the individual channels. In the dynamic flexi-grid
networks, not only an appropriate route is necessary to be selected
for the client LSP, but also the appropriate width of spectrum slot
is needed for the client LSP. The spectrum slot here is made up of
several consecutive spectrum slots from end-to-end, and is determined
by the data rate and the modulation level.
Zhao, et al. Expires July 13, 2013 [Page 4]
Internet-Draft P2MP in Flexi-Grid Networks January 2013
There are several drafts addressing the extensions of GMPLS protocols
to support the flexi-grid networks.
[draft-ogrcetal-ccamp-flexi-grid-fwk-01] defines a framework and the
associated control plane requirements for the GMPLS based control of
flexi-grid DWDM networks, and
[draft-farrkingel-ccamp-flexigrid-lambda-label-04] defines a new
GMPLS lambda label format to support flexi-grid. Besides,
[draft-dhillon-ccamp-super-channel-ospfte-ext-04] specifies the
extension to TELINK LSA of OSPF routing protocol in support of GMPLS
for flex-grid networks, and
[draft-hussain-ccamp-super-channel-label-04] defines a super-channel
label as a Super-Channel Identifier and an associated list of 12.5
GHz slices representing the optical spectrum of the super-channel.
This label format can be used in GMPLS signaling and routing protocol
to establish super-channel based optical label switched paths (LSPs).
This document covers the requirements for supporting P2MP over flexi-
grid infrastructure. First, section 3 provides some definitions
including background terminology and acronym list. Then, section 4
goes over a set of requirements that should be considered when
defining the protocol extensions to support P2MP in flexi-grid
networks. Next, the framework of extensions for supporting P2MP in
flexi-grid networks is presented in Section 5.
3. Definitions
3.1. Terminologies
Flexi-grid: a new technology allows mixed bit rates or mixed
modulation formats transmission system to allocate frequency slots
with different slot widths. So they can be optimized for the
bandwidth requirements of a particular bit rate and modulation scheme
of the individual channels.
Frequency Slot: a frequency slot is defined by its nominal central
frequency and its slot width. It denotes the frequency range
allocated to a channel, but unavailable for any other channels.
Spectral Slice: the minimum granularity of a frequency slot (e.g.
12.5 GHz).
Slot Width: the full width of a frequency slot in a flexible grid.
Frequency Range: a frequency range is defined as the portion of
frequency spectrum included between a lowest and a highest frequency.
P2MP tree: the ordered set of LSRs and TE links that comprise the
Zhao, et al. Expires July 13, 2013 [Page 5]
Internet-Draft P2MP in Flexi-Grid Networks January 2013
path of a P2MP TE LSP from its ingress LSR to all of its egress LSRs.
Ingress LSR: the LSR that is responsible for initiating the signaling
messages that set up the P2MP TE LSP.
Egress LSR: one of potential many destinations of the P2MP TE LSP.
Egress LSRs may also be referred to as leaf nodes or leaves.
Branch LSR: an LSR that has more than one directly connected
downstream LSRs.
Source: the sender of traffic that is carried on a P2MP service
supported by a P2MP LSP. The sender is not necessarily the ingress
LSR of the P2MP LSP.
Receiver: a recipient of traffic carried on a P2MP service supported
by a P2MP LSP. A receiver is not necessarily an egress LSR of the
P2MP LSP. Zero, one, or more receivers may receiver data through a
given egress LSR.
3.2. Acronyms
GMPLS: Generalized Multi-Protocol Label Switching
P2MP: Point-to-Multipoint
LSP: Label Switched Paths
LSR: Label Switched Router
WXC: Wavelength Cross Connect
WSS: Wavelength Selective Switch
4. Requirements for Supporting P2MP in Flexi-grid Networks
4.1. Requirements description
The broadcast-and-select mechanism at the WXC node by employing
bandwidth-variable WSS is suitable for multicasting traffic. This
document covers the high level requirements for the support P2MP over
flexi-grid infrastructure.
[Requirement 1 ] Flexible Bandwidth of P2MP LSP
The protocol should allow the P2MP LSP in the flexi-grid network to
be of different sizes/bandwidths. The number of Spectral Slices and
Zhao, et al. Expires July 13, 2013 [Page 6]
Internet-Draft P2MP in Flexi-Grid Networks January 2013
the granularity of each slice could be flexible.
[Requirement 2 ] Flexible mapping of P2MP LSP
This means the P2MP LSP should be allowed to be mapped to any
Frequency Range in the ITU grid. Note that the Frequency Range
allocation of P2MP LSP on the ITU-Grid shall confirm to [G.FLEXGRID].
[Requirement 3 ] Consecutive Frequency Range of P2MP LSP
This means that the spectral resources allocated to P2MP LSP must be
consecutive.
[Requirement 4 ] Flexibly choose the modulation format for P2MP LSP
Each channel mapped to the flexi-grid system shall have the
capability to support different modulation formats, e.g. BPSK, QPSK,
8PSK, 16QAM, 64QAM, and so on.
[Requirement 5 ] Bandwidth Resizing of P2MP LSP
Since the bandwidth of P2MP LSP depends on the modulation format of
the signal, the protocol shall allow bandwidth resizing if the
modulation format of optical signal changes.
[Requirement 6 ] Bandwidth Resizing for subset of P2MP LSP
Moreover, the extended protocol should support the functionality
which allows a subset of the P2MP LSP bandwidth resizing, e.g.,
changing the modulation format of optical signal.
4.2. Examples for Requirements
In the current optical networks, a single given modulation format,
such as BPSK, QPSK, and most recently n-QAM is employed. In P2MP
scenario, there may be more than one destination LSR, and each
destination LSR has a different path length. The design of the
system ensures that the longest path can be transmitted with a
sufficient quality of signal. Therefore, at the transmitter of all
destination LSRs have the highest modulation format and occupy the
largest spectral width regardless of the different optical path
length. Thus, some paths shorter than the others result in
overspending of network resources.
However, in the flexi-grid networks, the modulation format can be
elastically selected based on the length of the LSP. The different
assignment of spectral bandwidth of P2MP LSP for each destination LSR
(including Egress LSR and branch LSR) is based on the different
Zhao, et al. Expires July 13, 2013 [Page 7]
Internet-Draft P2MP in Flexi-Grid Networks January 2013
modulation format by varying the number of bits per symbol, for
example QPSK (2 bits per symbol) for one destination LSR and 16QAM (4
bits per symbol) for another. Note that the increasing of modulation
levels lies in the narrower spacing of symbols of signal
constellation, resulting in receiver sensitivity deterioration.
Here is an example for P2MP in flexi-grid network as shown in figure
1.
Egress LSR
+++++
- + F +
Ingress Branch - +++++
LSR LSR LSR LSR LSR - Receiver
+++++ +++++ +++++ +++++ +++++ -
+ A + --- + B + --- + C + --- + D + --- + E + -
+++++ +++++ +++++ +++++ +++++ -
Source - LSR Egress LSR
- +++++ +++++
- + G + --- + H +
+++++ +++++
Receiver
Figure 1 An example for bandwidth resizing of P2MP LSP
There is a P2MP request from Node A to Nodes F and H, and suppose its
bit rate is 60Gbit/s. When we construct a P2MP tree like figure 1,
the hops from A to F is 5, and from A to H is 6. Suppose a LSP which
has more than 5 hops must take QPSK modulation level for reducing the
nonlinear transmission impairments. then, in order to ensure that the
worst case optical path in this P2MP request, usually we take QPSK as
the modulate level. Here, 60 GHz spectral resources are needed.
Since the minimum granularity of a Frequency Slot is 12.5 GHz, a
frequency slot consisting 5 spectral slices with the Slot Width being
62.5 GHz are used. Note that these 5 frequency slices must be
consecutive in the spectral domain.
In the first scenario, link A-B has not enough spectral resources,
e.g. only has 4 spectral slices being consecutive. So we could
change the modulate level if we want to route this P2MP LSP
successfully. Here, we change the modulation level from QPSK to
16QAM. That's mean only 3 spectral slices are needed here.
In the second scenario, link A-B has not enough spectral resources,
e.g. only has 4 spectral slices being consecutive. Under the
assumption that O/E/O converting is permitted at the middle nodes, we
Zhao, et al. Expires July 13, 2013 [Page 8]
Internet-Draft P2MP in Flexi-Grid Networks January 2013
could cut this P2MP LSPs into three parts, one from A to D, one from
D to F, and the third one from D to H. For the LSP from A to D, we
take 16QAM as its modulation level; for the LSP from D to F, we take
64 QAM as the modulation level; and for the LSP from D to H, we take
16 QAM as the modulation level. That's means that only 3, 2, 3
spectral slices are needed here respectively.
5. Framework of Protocol Extensions
Mixed bitrate transmission systems can allocate their channels with
different spectral bandwidths so that the channels can be optimized
for the bandwidth requirements of the particular bit rate and
modulation format of the individual channels. A flexible grid
network selects its data channels as arbitrarily assigned spectral
slices. It is being developed within the ITU-T Study Group 15 to
allow the selection and switching of individual lambdas chosen
flexibly from a detailed, fine granularity grid of wavelength with
arbitrary spectral bandwidth [G.FLEXIGRID]. Our analysis has
determined that there are significant problems with existing
protocols for supporting P2MP in flexi-grid networks. The problems
include RSVP, OSPF, PCE, PCEP and so on. So additional extensions
may be needed because of new features introduced by flexible grid.
This section addresses the framework extensions of the requirements.
5.1. Signaling
RFC [4875] describes extensions to Resource reSerVation Protocol-
Traffic Engineering (RSVP-TE) for the setup of Traffic Engineered
(TE) P2MP Label Switched Paths (LSPs) in MPLS and GMPLS networks.
This section outlines RSVP-TE extensions for the support of P2MP in
flexi-grid networks. The ingress and egress nodes of the LSP must be
capable of indicating whether the Link-State and the modulation
format of the LSP should be collected during the signaling procedure
of setting up the LSP, and the endpoints of the LSP may collect the
Link-State and modulation format information and use it for
configuration purposes. When the Link-State and the modulation
format of a LSP changes, e.g., if the administrator changes the route
of a LSP, the endpoints of the LSP need to be capable of updating the
Link-State information and the modulation format information of the
LSA. During a new P2MP LSP establishment, each node along the path
allocates the required number of spectral slices and also learns the
other optical parameters.
5.2. Routing
RFC [3630] describes extensions to the OSPF protocol version 2 to
support intra-area traffic engineering, using Opaque Link State
Zhao, et al. Expires July 13, 2013 [Page 9]
Internet-Draft P2MP in Flexi-Grid Networks January 2013
Advertisements. This section outlines OSPF-TE extensions for the
support of P2MP in flexi-grid networks. As for stateful PCE, the PCE
has a TED plus an LSP-DB which are the active LSPs state (e.g. the
route and the slot used by a working LSP). So no extensions needed
here; As for stateless PCE, the TED may be filled through OSPF-TE,
thus OSPF-TE extensions may be required to carry used frequency slot
information, such as the associated bit-rate and modulation format.
5.3. PCE
The Path Computation Element (PCE) defined in [RFC4655] provides path
computation functions in support of traffic engineering in GMPLS
networks. It is an entity that is capable of computing a network
path or route based on a network graph and of applying computational
constraints. [RFC4655] also defines various deployment models that
place PCEs differently within the network. The PCEs may be
collocated with the Label Switching Routers (LSRs), may be part of
the management system that requests the LSPs to be established, or
may be positioned as one or more computation servers within the
network.
This part examines the applicability of PCE to path computation for
P2MP TE LSPs in Flexi-grid networks. As for stateful PCE, PCE has a
TED plus an LSP-DB which are the active LSPs state; and as for
stateless PCE, PCE exploits a TED which includes per-link information
regarding the usage of the optical spectrum resource. In order to
identify the information of the route, the TED plus the LSP-DB
exploited by the PCE should be extended to store the following
information:
o Bit rate of any working LSP in the network.
o Modulation format of any working LSP in the network.
o Allocated central frequency and slot width for any active LSP in
the network.
5.4. PCEP
RFC [5862] complements the general requirements and presents a
detailed set of PCC-PCE communication protocol requirements for P2MP
MPLS/GMPLS traffic engineering. This part examines the applicability
of PCEP to path computation for P2MP TE LSPs in Flexi-grid networks.
Similar with PCE, an extension may be needed in the PCEP Path
Computation Reply message to inform the ingress node about the
following information along the route:
Zhao, et al. Expires July 13, 2013 [Page 10]
Internet-Draft P2MP in Flexi-Grid Networks January 2013
o Bit rate of any working LSP in the network.
o Modulation format of any working LSP in the network.
o Allocated central frequency and slot width for any active LSP in
the network.
6. Security Considerations
TBD.
7. IANA Considerations
TBD.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC 4461, April 2006.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients
(PCC) "C Path Computation Element (PCE) Requirements for
Point-to-Multipoint MPLS-TE", RFC 5862, June 2010.
Zhao, et al. Expires July 13, 2013 [Page 11]
Internet-Draft P2MP in Flexi-Grid Networks January 2013
8.2. Informative References
[1] ITU-T, "Draft revised G.694.1 version 1.6", December 2011.
[2] Gonzalez de Dios, O., Casellas, R., Zhang, F., Fu, X.,
Ceccarelli, D., and I. Hussain,
"draft-ogrcetal-ccamp-flexi-grid-fwk-01", October 2012.
[3] King, D., Farrel, A., Li, Y., Zhang, F., and R. Casellas,
"draft-farrkingel-ccamp-flexigrid-lambda-label-04",
October 2012.
[4] Dhillon, A., Hussain, I., Rao, R., and M. Sosa,
"draft-dhillon-ccamp-super-channel-ospfte-ext-04",
November 2012.
[5] Hussain, I., Dhillon, A., Pan, Z., Sosa, M., Basch, B.,
Liu, S., and Andrew G. Malis,
"draft-hussain-ccamp-super-channel-label-04", September
2012 .
Appendix A. Acknowledgments
The RFC text was produced using Marshall Rose's xml2rfc tool.
Authors' Addresses
Yongli Zhao
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613811761857
Email: yonglizhao@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Zhao, et al. Expires July 13, 2013 [Page 12]
Internet-Draft P2MP in Flexi-Grid Networks January 2013
Xiaosong Yu
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613811731723
Email: xiaosongyu@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Jie Zhang
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613911060930
Email: lgr24@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Jiayu Wang
ZTE Corporation
No.16,Huayuan Road,Haidian District
Beijing 100191
P.R.China
Phone: +861061198108
Email: wang.jiayu1@zte.com.cn
URI: http://www.zte.com.cn/
Xuefeng Lin
ZTE Corporation
No.16,Huayuan Road,Haidian District
Beijing 100191
P.R.China
Phone: +8615901011821
Email: lin.xuefeng@zte.com.cn
URI: http://www.zte.com.cn/
Zhao, et al. Expires July 13, 2013 [Page 13]
