4
IEEE Communications Magazine • March 2013 28 COMMENTARY SOFTWARE DEFINED NETWORKING OPPORTUNITIES FOR TRANSPORT BY DAVE MCDYSAN, VERIZON ABSTRACT The economic landscape where trends of computing and networking are diverging creates motivation for new engineer- ing paradigms. One emerging paradigm is software defined networking, whose attributes include separation of control from forwarding, enabling joint optimization of computing and networking deployments, software-defined functions at a num- ber of layers, including the transport (i.e., optical and TDM) layer, enabling simpler interworking of different administrative and technology domains, and application-aware transport net- work resources. This column provides some background on the aspects of SDN related to transport networking, summarizes major drivers, trends, and issues to be addressed, and con- cludes by discussing areas of potential research and develop- ment for transport-related future SDN work. INTRODUCTION Software defined networking (SDN) is an acronym that has been assigned a number of interpretations since its earliest mention in the literature [1]. This column focuses on the fol- lowing aspects of SDN relevant to transport networking: • Separation of control from forwarding to enable new or enhanced paradigms based on abstractions of the for- warding technology to enable new or improved network and service structures [1, 2] • Enable extraction of simplicity instead of managing the ever increasing complexity of networking [2] • Support logically centralized control implementations that are more efficient than current distributed system implementations and overcome limitations of these lega- cy systems [3, 4] • Software definable forwarding (modulation/demodula- tion, encoding/decoding, etc.). Much work is occurring on software-defined radio technology, and some of this may be applicable to software-defined optical technology. • Allow transport networks in different domains to be intelligently interconnected and managed using dynami- cally controlled and coordinated multilayer network capabilities to meet service needs [5] • Enable cross stratum optimization in complex multilayer systems, which include computing, storage, and application resources as well as transport and packet networks [4] • Enable simple implementation of software defined transponders and flexible grid and elastic networking • Provide virtualized, partitioned network views to service provider customers so that they can dynamically signal bandwidth and other requirements via either an overlay and/or interworking with traditional control and manage- ment plane protocols DRIVERS FOR SOFTWARE-DEFINED TRANSPORT NETWORKING A number of drivers for SDN-based transport networking are created by trends in relative price-performance of computing and networking technologies, better matching the network to user traffic patterns, and using direct transport communica- tion when warranted for cloudbursting type services. The price to achieve the same level of throughput and per- formance for processing and storage is declining much faster than the price of routing and transmission. The price-perfor- mance of electronic routing and switching is decreasing more rapidly than that of transport systems, whose price-perfor- mance is improving at the slowest rate. Transport system price-performance is decreasing more slowly than the other technologies for a number of reasons, including the complexi- ty of modulation, encoding, and impairment compensation at very high line rates (e.g., 100 Gb/s), the need to aggregate traffic onto fewer transport routes to achieve the lower unit cost of higher line rates, and the lower overall deployed vol- ume of interface capacity compared with processing, storage, and routers/switches deployed in data centers where each packet may traverse many devices. These trends motivate deployment of processing and storage that implement middle box and/or server-based services in more distributed network locations since this decreases the overall cost of providing services compared with carrying traffic back and forth via an indirect route to a regionalized data cen- ter [6]. Furthermore, placing processing and shared storage closer to users can achieve very low-latency highly interactive application performance. Since transport system price perfor- mance is improving at the slowest rate, there is a tremendous need to make transmission systems more responsive to applica- tion traffic patterns and service provider needs and reduce the number of transport components in the network. Regular patterns of time of day and day of week usage are seen for specific classes of users and access networks. For example, enterprise users generate most traffic during week- days and normal business hours, while on the other hand con- sumers typically generate most traffic during nights and weekends. This means that time of day sharing between enter- prise and consumer usage patterns is possible. Rearranging transport network topologies to interconnect networking and computing more economically based on time of day and day of week to better serve these predictable phases of behaviors could significantly reduce overall networking cost. The economics of virtualization will compel enterprises to outsource computing needs to network-based cloud and virtu- al private network (VPN) providers. Transferring computing state and storage to other locations in a reasonable timeframe requires commensurate bandwidth for the duration of such transfers, and transport communication should be the least expensive networking method when there is a requirement for a large amount of relatively constant traffic in a point-to-point or broadcast manner. A difficulty for many applications is to accurately deter- mine the network parameters (e.g., bandwidth and quality measures such as latency and loss) that are needed to meet higher-level service objectives. However, signaling such parameters for every session has serious scaling challenges. Instead, network traffic engineering is usually done at an aggregate level, providing statistical guarantees for quality. What is needed is a closer tie between application needs and the combination of resources (e.g., transport networking, elec- tronic networking, computing, and storage). Time of day and time zone optimization, where non-real-time applications can be shifted to other locations with spare computing and net- work capacity and/or different power usage rates, can be employed to reduce the cost of providing services [6].

Verizon SDN Opportunities for Transport

Embed Size (px)

Citation preview

Page 1: Verizon SDN Opportunities for Transport

IEEE Communications Magazine • March 201328

COMMENTARY

SOFTWARE DEFINED NETWORKING OPPORTUNITIES FOR TRANSPORTBY DAVE MCDYSAN, VERIZON

ABSTRACT

The economic landscape where trends of computing andnetworking are diverging creates motivation for new engineer-ing paradigms. One emerging paradigm is software definednetworking, whose attributes include separation of controlfrom forwarding, enabling joint optimization of computing andnetworking deployments, software-defined functions at a num-ber of layers, including the transport (i.e., optical and TDM)layer, enabling simpler interworking of different administrativeand technology domains, and application-aware transport net-work resources. This column provides some background on theaspects of SDN related to transport networking, summarizesmajor drivers, trends, and issues to be addressed, and con-cludes by discussing areas of potential research and develop-ment for transport-related future SDN work.

INTRODUCTIONSoftware defined networking (SDN) is an acronym that hasbeen assigned a number of interpretations since its earliestmention in the literature [1]. This column focuses on the fol-lowing aspects of SDN relevant to transport networking:• Separation of control from forwarding to enable new or

enhanced paradigms based on abstractions of the for-warding technology to enable new or improved networkand service structures [1, 2]

• Enable extraction of simplicity instead of managing theever increasing complexity of networking [2]

• Support logically centralized control implementationsthat are more efficient than current distributed systemimplementations and overcome limitations of these lega-cy systems [3, 4]

• Software definable forwarding (modulation/demodula-tion, encoding/decoding, etc.). Much work is occurringon software-defined radio technology, and some of thismay be applicable to software-defined optical technology.

• Allow transport networks in different domains to beintelligently interconnected and managed using dynami-cally controlled and coordinated multilayer networkcapabilities to meet service needs [5]

• Enable cross stratum optimization in complex multilayersystems, which include computing, storage, and applicationresources as well as transport and packet networks [4]

• Enable simple implementation of software definedtransponders and flexible grid and elastic networking

• Provide virtualized, partitioned network views to serviceprovider customers so that they can dynamically signalbandwidth and other requirements via either an overlayand/or interworking with traditional control and manage-ment plane protocols

DRIVERS FOR SOFTWARE-DEFINEDTRANSPORT NETWORKING

A number of drivers for SDN-based transport networking arecreated by trends in relative price-performance of computingand networking technologies, better matching the network touser traffic patterns, and using direct transport communica-tion when warranted for cloudbursting type services.

The price to achieve the same level of throughput and per-formance for processing and storage is declining much fasterthan the price of routing and transmission. The price-perfor-mance of electronic routing and switching is decreasing morerapidly than that of transport systems, whose price-perfor-mance is improving at the slowest rate. Transport systemprice-performance is decreasing more slowly than the othertechnologies for a number of reasons, including the complexi-ty of modulation, encoding, and impairment compensation atvery high line rates (e.g., 100 Gb/s), the need to aggregatetraffic onto fewer transport routes to achieve the lower unitcost of higher line rates, and the lower overall deployed vol-ume of interface capacity compared with processing, storage,and routers/switches deployed in data centers where eachpacket may traverse many devices.

These trends motivate deployment of processing and storagethat implement middle box and/or server-based services inmore distributed network locations since this decreases theoverall cost of providing services compared with carrying trafficback and forth via an indirect route to a regionalized data cen-ter [6]. Furthermore, placing processing and shared storagecloser to users can achieve very low-latency highly interactiveapplication performance. Since transport system price perfor-mance is improving at the slowest rate, there is a tremendousneed to make transmission systems more responsive to applica-tion traffic patterns and service provider needs and reduce thenumber of transport components in the network.

Regular patterns of time of day and day of week usage areseen for specific classes of users and access networks. Forexample, enterprise users generate most traffic during week-days and normal business hours, while on the other hand con-sumers typically generate most traffic during nights andweekends. This means that time of day sharing between enter-prise and consumer usage patterns is possible. Rearrangingtransport network topologies to interconnect networking andcomputing more economically based on time of day and dayof week to better serve these predictable phases of behaviorscould significantly reduce overall networking cost.

The economics of virtualization will compel enterprises tooutsource computing needs to network-based cloud and virtu-al private network (VPN) providers. Transferring computingstate and storage to other locations in a reasonable timeframerequires commensurate bandwidth for the duration of suchtransfers, and transport communication should be the leastexpensive networking method when there is a requirement fora large amount of relatively constant traffic in a point-to-pointor broadcast manner.

A difficulty for many applications is to accurately deter-mine the network parameters (e.g., bandwidth and qualitymeasures such as latency and loss) that are needed to meethigher-level service objectives. However, signaling suchparameters for every session has serious scaling challenges.Instead, network traffic engineering is usually done at anaggregate level, providing statistical guarantees for quality.What is needed is a closer tie between application needs andthe combination of resources (e.g., transport networking, elec-tronic networking, computing, and storage). Time of day andtime zone optimization, where non-real-time applications canbe shifted to other locations with spare computing and net-work capacity and/or different power usage rates, can beemployed to reduce the cost of providing services [6].

MCDYSAN LAYOUT_LYT/PRES PAGE/OCT 3/1/13 1:10 PM Page 28

Page 2: Verizon SDN Opportunities for Transport

IEEE Communications Magazine • March 2013 29

EXAMPLES OF SDN TRANSPORT NETWORKING USE CASES

This section provides illustrative examples and references torelated publications that provide greater detail. The use casescovered are coordinated networking and computing for acloudbursting style service, multilayer and cross computingand networking stratum optimization, and multidomain andmultilayer networking optimization.

COORDINATED NETWORKING ANDCOMPUTING FOR CLOUDBURSTING

Figure 1 illustrates a simple example environment for coordi-nating networking and computing between an enterprise datacenter connected via a packet and transport network to twoservice provider cloud data centers. Cloudbursting is a termused to describe an event in which an enterprise wishes totemporarily augment its data center capacity (e.g., processing,storage, software) by purchasing this capacity in a cloudprovider data center. Something missing in cloudburstingtoday is efficiently coupling the network and its propertieswith the computing environment [7, 8]. Cloud bursting isdesirable when large amounts of data need to be moved tothe cloud for initial service activation (e.g., moving the cus-tomer’s database and/or virtual machine [VM] instances intothe cloud), to support migration of the cloud service forresource optimization, or to implement high-bandwidth stor-age replication.

As shown in Fig. 1a, packet networks normally intercon-nect customer applications located in private enterprise datacenters to cloud provider data centers. These packet networksmay offer bandwidth on demand features, which are usefulwhen the bandwidth is relatively low (e.g., n¥1GE). However,when the capacity requirement for communication betweenenterprise and cloud data centers becomes large (e.g., 10 GE),

a more efficient solution could be to use dynamically config-ured transport connections instead of packet networking, asillustrated in Fig. 1b. Additionally, to meet customer require-ments, there may be a choice between cloud provider datacenters to meet customer application requirements for diversi-ty and latency and/or select the cloud data center with avail-able capacity. OpenFlow-based SDN can be used toimplement such a networking scheme [7]. In some cases, inorder to achieve improved efficiency and avoid blocking, itmay be necessary to rearrange the underlying transport con-nectivity for the packet network as shown in the figure. Thiswill require the OpenFlow controller to work with traditionalpacket and transport management and control plane systems.What is needed is an integration of cloud computing withmultilayer networking bandwidth on demand features in het-erogeneous network.

GLOBAL OPTIMIZATION OF TRANSMISSION, SWITCHING,COMPUTING, AND STORAGE

Figure 2 shows a simple example of three data centers inter-connected by packet and transport network elements. Thedata centers have a logical packet reachability requirementthat is full mesh. Figure 2a shows how the logical full meshpacket reachability is achieved by the packet switches P.A,P.B, and P.C using transport connectivity between P.A to P.Cand P.A to P.B over the corresponding transport switches T.Ato T.C and T.A to T.C, respectively. Instead of drawing thefull mesh of packet flows, the dots in packet switches P.A andP.B show how packet switching in these nodes implement thelogical full mesh. Similar to the cloudbursting scenario previ-ously described, a service provider may have a need tomarkedly increase the capacity between specific data centers.In the example of Fig. 2b, there is a need to provide increasedcapacity between data centers A and C. In this example, thepacket network connectivity is rearranged, and full mesh logi-cal packet reachability is maintained, but now a more efficient

COMMENTARY

Figure 1. Example for coordinating virtual networking and computing: a) packet networking operation; b) SDN-based multilayer networking.

(a)

nx1GE

10GE

Clouddata center

Enterprisedata center

Clouddatacenter

Packetswitch,router

Transportswitch

Datacenter

Packetflow

Transportflow

Physicalinterface

(b)

nx1GE

10GE

Clouddata center

Enterprisedata center

Clouddatacenter

MCDYSAN LAYOUT_LYT/PRES PAGE/OCT 3/1/13 1:10 PM Page 29

Page 3: Verizon SDN Opportunities for Transport

IEEE Communications Magazine • March 201330

transport flow path can be dynamically configured connectingdata centers A and C. The overall management system mustmake changes in the relevant equipment in data centers Aand C to direct traffic onto this transport flow path. EitherOpenFlow or a stateful path computation element (PCE) [9]approach could be used to implement this SDN-based net-working paradigm. Of course, one would not want to rear-range the underlying connectivity of the packet switches toofrequently, because this can cause packet reordering andpotentially packet loss.

A promising approach might be a stateful PCE [9] thatcan be commanded to apply specific policies on labelswitched path (LSP) signaling messages via an external SDNcontrol system that can optimize one or more of the charac-teristics not optimized by a distributed signaling and routingsystem, such as those in the examples of this article and thecited references where the transport network below thepacket network is rearranged to more efficiently serve spe-cific traffic patterns. In particular, another use of the statefulPCE approach is in cross stratum optimization (CSO) acrossa network stratum (transmission, switching, PCE) and anapplication stratum (computing, software, and storageresources) [4]. Users interact with an application stratumcontroller, which can query and command one or more net-work stratum controllers. The network controllers may com-municate with one or more PCEs, and there may also becommunication between network controllers. The networkcontroller provides an abstraction to the application con-troller regarding attributes of the underlying network layersand domains. Combining this network-level information withknowledge of computing resources, the application con-troller is able to make globally optimized decisions regardingplacement of compute and storage resources in specific datacenter sites along with the required multilayer networkingcapacity. A study based on a 14-node topology showed areduction in blocking probability of 10 to 20 percent for

wavelength provisioning for joint application and networkoptimization vs. a strategy that selected only the data centersite with the lowest utilization [4].

MULTILAYER AND INTERDOMAIN OPTIMIZATIONFigure 3 shows a simple example illustrating multilayer andinterdomain optimization for data center interconnection. Inthe drawing, there are two domains (e.g., service providers,organizations within an enterprise), each having its own set ofinterconnected data center, packet, and transport elements.Figure 3a shows a typical case where the transport networkflows connect a set of packet switches in an underlay manner.As previously described, the packet switches implement logi-cal full mesh packet reachability overlaid on these transportflows (note that the packet flows are not shown in the figurein the interest of clarity). In this example, a need arises to cre-ate a large amount of capacity between data centers B.1 andA.2. The packet network may not have sufficient capacity, ormay not be able to support this demand economically. Figure3b shows a potential solution to this problem involving recon-figuration of the transport underlay for the packet network tofree up capacity and provide a direct transport (e.g, time-divi-sion multiplexing or lambda) connection between data centersB.1 and A.2. Current interdomain multilayer routing and sig-naling standards do not support this capability. What is need-ed to achieve this result is a higher-level SDN-based interfacethat can perform this resource discovery and configurationacross multiple domains.

Various standards bodies (e.g., Internet Engineering TaskForce, Optical Internet Forum) have been working on extend-ing packet-based routing (e.g., IGP) and signaling (e.g.,RSVP-TE) standards to support transport-based profiles. Thissuite of standards is often referred to as general multiprotocollabel switching (GMPLS) and has been implemented by anumber of transmission vendors. However, the distributedrouting and signaling GMPLS approach has some known sub-

COMMENTARY

Figure 2. Example for multilayer optimization of transport and packet switching: a) packet networking operation; b) SDN-based multi-layer networking.

(a)

Logical full mesh packet reachability overlaid on transport

T.A.

P.A. P.B.

T.B.

T.C.

P.C.

Packetswitch,router

Transportswitch

Datacenter

Packetflow

Transportflow

Physicalinterface

(b)

Logical full mesh packet reachability overlaid on transport

T.A.

Dynamicallyinstantiatedtransport flow

P.A. P.B.

T.B.

T.C.

P.C.

A B

C

A B

C

MCDYSAN LAYOUT_LYT/PRES PAGE/OCT 3/1/13 1:10 PM Page 30

Page 4: Verizon SDN Opportunities for Transport

IEEE Communications Magazine • March 2013 31

optimal characteristics [3], such as inefficient bin packing, lackof determinism for LSP placement, potential for creatingdeadlocks, and lack of support for scheduling/calendaring theplacement of traffic onto transmission and packet layer equip-ment. An important requirement for multilayer and interdo-main networking is that of route selection [5], which could beimplemented using stateful PCE to specify explicit routes in a(G)MPLS routed network.

SUMMARY AND CONCLUSIONSA revolution is occurring in the world of networking andcomputing. This revolution will not suddenly replace all ofour existing network infrastructures — it will emerge as aliving, evolving computing and networking overlay that inter-works with traditional control and management plane func-tions in packet and transport networks deployed inenterprises, service providers, and data centers. In effect,stateful PCE and OpenFlow approaches extract simplicity inthe form of an abstraction that more directly maps to thereal world problems being solved. Further work is needed tomore precisely define the needed abstractions, and createsoftware and standards that can leverage already deployednetwork elements and operational support systems. Thefocus should be on integration of cloud computing with mul-tilayer networking bandwidth on demand features in hetero-geneous networks.

As part of this effort, research, development, experimenta-tion, and standardization will be needed; initially, on controlparadigms beyond those of legacy routing and switching thatis provably correct, stable, and scalable will be an importantfoundation for the future. Development using new/evolvedprotocols, such as OpenFlow and stateful PCE, modern man-agement interfaces and higher-level application programminginterfaces (APIs) to solve new problems and/or realize signifi-cant optimization as proof of concept prior to standardizationis important in a software-defined world. Experimentation inlaboratories and field trials is the next important step to

ensure operability and manageability. For certain aspectsmature standards will be needed to ensure interoperabilityand reusability.

REFERENCES[1] G. Goth, “Software-Defined Networking Could Shake Up More than

Packets,” IEEE Internet Computing, July/Aug. 2011.[2] S. Shenker, “The Future of Networking, and the Past of Protocols,”

Open Networking Summit, Oct. 18, 2011, http://opennetsummit.org/talks/shenker-tue.pdf.

[3] E. Crabbe and V. Valancius, “SDN at Google Opportunities for WANOptimization,” IETF 84, Vancouver, Aug. 1, 2012, http://www.ietf.org/proceedings/84/slides/slides-84-sdnrg-4.pdf.

[9] E. Crabbe et al., “PCEP Extensions for Stateful PCE,” IETF, Jan 22, 2012,work in progress.

[5] A. Isogai et al., “Global-Scale Experiment on Multi-Domain SoftwareDefined Transport Network,” 10th Int’l. Conf. Optical Internet, Yoko-hama, Japan, May 29–31, 2012.

[7] Open Networking Foundation, “OpenFlow-Enabled Hybrid Cloud Ser-vices Connect Enterprise and Service Provider Data Centers,” Nov 13,2012, https://www.opennetworking.org/images/stories/downloads/solu-tion-briefs/sb-hybrid-cloud-services.pdf.

[4] D. Dhody, Y. Lee, and H. Yang, “Cross Stratum Optimization (CSO)Enabled PCE Architecture,” 2012 10th IEEE Int’l. Symp. Parallel and Dis-tributed Processing with Applications, 10–13 July, 2012, Madrid, Spain.

[6] Intel, “ Software-Defined Networking and Services on Intel® Proces-sors,” 2012, http://www.intel.com/content/www/us/en/communica-tions/communications-sw-defined-networking-paper.html.

[8] D. McDysan, “Cloudbursting Use Case,” IETF Internet-Draft, work-in-progress, Oct. 2011.

BIOGRAPHYDAVID E. MCDYSAN [SM] ([email protected]) received a B.S. degreein electrical engineering from Virginia Tech, and M.S. and D.Sc. degrees inelectrical engineering and computer science from George Washington Uni-versity in 1976, 1979, and 1989, respectively. He is employed as a PrincipalMember of Technical Staff in the Verizon network architecture department.His responsibilities and interests include cloud computing infrastructure,software infrastructure, IP and data services technology and standards, soft-ware-defined networking, and how these relate to the overall service andnetwork architecture. He works to investigate new and emerging technolo-gies, define architectural approaches for these technologies, interacts withother organizations to address important business aspects, and models theeconomic and performance advantages of new and refined architectures.

COMMENTARY

Figure 3. Example for multilayer and interdomain optimization: a) packet networking; b) SDN-based multilayer networking.

(a)

A.1

Packetswitch,router

Transportswitch

Datacenter

Packetflow

Transportflow

Physicalinterface

A.2

B.1

Domain 1 Domain 2

Logical full mesh packet reachability overlaid on transport

B.2

(b)

A.1

Dynamicallyinstantiatedtransport flow

Domain 1 Domain 2

Logical full mesh packet reachability overlaid on transport

B.2B.1

A.2

MCDYSAN LAYOUT_LYT/PRES PAGE/OCT 3/1/13 1:10 PM Page 31